[address-policy-wg] [arano at inetcore.com: [GLOBAL-V6] Fwd: [sig-policy] prop-046: IPv4 countdown policy proposal]

Hi,

this is a policy currently discussed in the APNIC region.

I haven't formed an opinion of my own on this yet, but I think it might
be useful to be aware of it.

Gert Doering,
	APWG Chair

----- Forwarded message from Takashi Arano <arano at inetcore.com> -----

X-IronPort-SBRS: 3.5
X-Greylist: delayed 1099 seconds by postgrey-1.21 at kombu.apnic.net;
	Tue, 30 Jan 2007 20:45:27 EST
X-Mailer: QUALCOMM Windows Eudora Version 6.2J rev4.2
Date: Tue, 30 Jan 2007 19:26:35 +0900
To: global-v6 at lists.apnic.net
From: Takashi Arano <arano at inetcore.com>
X-AP-Spam-Status: No, hits=0 required=6
X-AP-Spam-Status: No, hits=0 required=6
X-AP-Spam-Score: 0 (notspam) 
X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang)
X-Mailman-Approved-At: Wed, 31 Jan 2007 08:40:22 +1000
Subject: [GLOBAL-V6] Fwd: [sig-policy] prop-046: IPv4 countdown policy
	proposal
X-BeenThere: global-v6 at lists.apnic.net
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: Discussion of new global IPv6 policy development
	<global-v6.lists.apnic.net>
X-AP-Lists: Discussion of new global IPv6 policy development
	<global-v6.lists.apnic.net>
List-Unsubscribe: <http://mailman.apnic.net/mailman/listinfo/global-v6>,
	<mailto:global-v6-request at lists.apnic.net?subject=unsubscribe>
List-Archive: <http://www.apnic.net/mailing-lists/global-v6>
List-Post: <mailto:global-v6 at lists.apnic.net>
List-Help: <mailto:global-v6-request at lists.apnic.net?subject=help>
List-Subscribe: <http://mailman.apnic.net/mailman/listinfo/global-v6>,
	<mailto:global-v6-request at lists.apnic.net?subject=subscribe>
Errors-To: global-v6-bounces at lists.apnic.net

All,

Hello.
I will forward our proposal to this mailing list just FYI.
It is not an IPv6 policy, though.

Regards,
Takashi Arano

>X-Original-To: arano at inetcore.com
>Delivered-To: arano at inetcore.com
>From: "Kenny Huang" <huangk at alum.sinica.edu>
>To: <sig-policy at apnic.net>
>Date: Tue, 30 Jan 2007 15:51:34 +0800
>X-Mailer: Microsoft Office Outlook, Build 11.0.6353
>Thread-Index: AcdEKKt/vRhEhwUHSvaQIKaDUzp1lAAGqTXQ
>X-AP-Spam-Status: No, hits=0 required=6
>X-AP-Spam-Status: No, hits=0 required=6
>X-AP-Spam-Score: 0 (notspam) 
>X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang)
>Cc: 
>Subject: [sig-policy] prop-046: IPv4 countdown policy proposal
>X-BeenThere: sig-policy at lists.apnic.net
>X-Mailman-Version: 2.1.4
>List-Id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net>
>X-AP-Lists: APNIC SIG on resource management policy<sig-policy.lists.apnic.net>
>List-Unsubscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>,<mailto:sig-policy-request at lists.apnic.net?subject=unsubscribe>
>List-Archive: <http://www.apnic.net/mailing-lists/sig-policy>
>List-Post: <mailto:sig-policy at lists.apnic.net>
>List-Help: <mailto:sig-policy-request at lists.apnic.net?subject=help>
>List-Subscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>,<mailto:sig-policy-request at lists.apnic.net?subject=subscribe>
>Sender: sig-policy-bounces at lists.apnic.net
>
> 
>
>Dear SIG members
>
>Yesterday, the proposal "IPv4 countdown policy proposal" was sent to the
>Policy SIG for review. It will be presented at the Policy SIG at APNIC 23 in
>Bali, Indonesia, 26 February - 2 March 2007. You are invited to review and
>comment on the proposal on the mailing list before the meeting.
>
>The proposal's history can be found at:
>
>        http://www.apnic.net/policy/proposals/prop-046-v001.html
>
>Regards,
>
>Kenny Huang
>Policy SIG
>huangk at alum.sinica.edu
>
>
>prop-046-v001: IPv4 countdown policy proposal
>
>________________________________________________________________________
>
>
>
>Co-authors: Toshiyuki Hosaka (JPNIC)
>                        Takashi Arano (Intec Netcore, Inc.)
>             Kuniaki Kondo (Atelier Mahoroba)
>             Tomohiro Fujisaki (NTT)
>             Akinori Maemura (JPNIC)
>             Kosuke Ito (IRI Ubitech)
>             Shuji Nakamura (IPv6 Promotion Council)
>             Tomoya Yoshida (NTT Communications)
>             Susumu Sato (JPNIC)
>             Akira Nakagawa (KDDI)
>
>Version:    1
>
>Date:       29 January 2007
>
>SIG:        Policy
>
>
>1.  Introduction
>----------------
>
>The exhaustion of IPv4 address is approaching round the corner. Geoff
>Huston's latest projection at Potaroo (as of January 6, 2007)
>(http://www.potaroo.net/tools/ipv4/) draws the date of IANA pool exhaustion
>as 31st May 2011, and that of RIR pool as 14th July 2012.
>
>Tony Hain projects similar dates based on a different algorithm of his own.
>>>From these data, we may observe that if that the current allocation trend
>continues, the exhaustion of IPv4 address space is expected to take place as
>early as within the next five years.
>
>ICANN/IANA and RIRs must co-ordinate with stakeholders to achieve smooth
>termination of IPv4 address space as the Internet bodies responsible for
>stable management and distribution of IP number resources.
>
>This proposal provides some ideas as well as concrete examples of the policy
>that helps IPv4 allocations come to an end with "the minimum confusion" and
>in "as fair manner as possible".
>
>"Five years at the earliest" is not too far in the future for the exhaustion
>of IPv4 address space. Assuming the minimum of one year is required for
>sufficient policy discussions with this proposal as a start, and two years
>for preparation and transfer by LIRs, we need to start the discussions right
>at this time.
>
>
>
>2.  Summary of current problems
>-------------------------------
>
>Despite the fact that several projections are made on IPv4 address to run
>out as early as within the next few years, no discussions are taking place
>on any of the RIR's policy fora including that of APNIC.
>This section lists possible problems if no policies are defined to prepare
>for the terminal period of allocations.
>
>
>2.1 LIR
>
>        LIRs currently do not consider IPv4 address exhaustion as an
>        imminent issue in the first place. It is possible that they will
>        finally realize the situation only when impacts of the exhaustion
>        becomes visible as a practical matter, and lead to confusions such
>        as re-addressing their network or making subsequent requests at the
>        last minute in within a limited time frame.
>        
>        There could also be cases where allocations blocks cannot be
>        allocated       to some of the LIRs even though requests are
>submitted
>        on the same day. Moreover, although it would be necessary for LIRs
>        to announce to their customers that IPv4 address space will not be
>        available for assignments eventually, it is difficult to plan this
>        timing without clear policy     for the last phase of allocations.
>        
>        As new IPv4 address allocations space will no longer be available,
>        LIRs have no choice but to build networks based on IPv6. However,
>        there are risks of trouble if preparations are made from that point
>        in time, as it will lead to premature actions even if some time can
>        be bought by re-addressing and subsequent allocations.
>        
>        Lastly, using up all available IPv4 address space will disable
>        assignments to services inevitable for co-existence of IPv4 and
>        IPv6 networks, such as the translator service between the two
>        networks, which it may create situation where transfer to IPv6
>        network will not even be possible.
>
>
>2.2 RIR/NIR
>
>        It is likely that smooth allocations by RIRs/NIRs will be hindered
>        by rush of inquiries during the terminal phase of allocations.
>
>
>2.3 End users
>
>        End users generally receive address assignments from ISPs
>        accompanied with Internet connection service. If an ISP no longer
>        has IPv4 address space available, nor unable to provide IPv6
>        service, end users will not be able to receive services from that
>        ISP.
>        
>        Moreover, if the terminal date of allocations remains ambiguous,
>        it may leave end users behind to prepare for IPv6 ready network.
>
>
>
>3.  Benefits
>------------
>
>There will be the following benefits by implementing the policy for
>IPv4 address exhaustion as proposed on this paper.
>
>
>3.1 LIR
>
>        LIRs will be able to consciously plan their addressing within their
>        networks if the final date of allocations is clearly demonstrated.
>        Keeping a certain amount of unallocated address blocks enables
>        allocations/assignments for "critical infrastructure" after the
>        termination of regular allocations, which will be explained later
>        section in more details.
>
>
>3.2 RIR/NIR
>
>        Announcing the date of terminating allocations in advance and
>        ensuring that all allocations before this date will be made
>        according to the policy at the time enables RIRs/NIRs to make the
>        last allocation without confusions and avoids causing feelings of
>        unfairness among LIRs and end users. In addition, consistent policy
>        applied to all RIRs removes bias towards certain region as well as
>        inter-regional unfairness. The period which IPv6 support is
>        completed becomes clear, therefore, RIRs/NIRs can prepare for this.
>
>
>3.3 End user
>
>        As this proposal enables LIRs to prepare for the terminal period of
>        allocations in advance, it reduces the risk of delays/suspensions of
>        assignments from LIRs to enduers, and end users will be able to
>        continuously receive services from LIRs. As in the case of LIRs, end
>        users will be able to prepare for IPv6 support by the date of
>        allocation termination is clarified. In addition, IPv6 connectivity
>        as well as IPv4 address required during the allocation termination
>        period will be smoothly secured by LIRs preparing for such period.
>
>        As listed above, there will be important, notable benefits for
>        stakeholders as a result of this policy. It is therefore necessary
>        to take the following actions to achieve a smooth transfer to IPv6
>        and prevent causing instability in the Internet as well as;
>        
>        - start discussions on allocation scheme during the exhaustion
>           period,
>        
>        - indicate a roadmap to exhaustion after raising awareness on the
>           issue, and
>        
>        - allow enough time for LIRs to plan timing of addressing of their
>           networks, submit allocation requests, and consider how to switch
>           to IPv6.
>
>
>
>4.  Proposal
>-----------
>
>4.1  Principles
>
>        As the first step to discuss IPv4 exhaustion planning, we would
>        like to have an agreement(consensus) on the following four
>        principles.
>
>        --------------------------------------------------------------------
>        (1) Global synchronization:
>        
>                All five RIRs will proceed at the same time for measures on
>IPv4
>                address exhaustion.
>        
>        (2) Some Blocks to be left:
>        
>                Keep a few /8 stocks instead of distributing all.
>        
>        (3) Keeping current practices until the last moment :
>        
>                Maintain the current policy until the last allocation.
>        
>        (4) Separate discussions on "Recycle" issue :
>        
>                Recovery of unused address space should be discussed
>separately
>        --------------------------------------------------------------------
>        
>
>        (1) Global synchronization:
>
>                All RIRs must proceed at the same time to take measures for
>                IPv4 address exhaustion. This is important not only for
>ensuring
>                fairness for LIRs across the regions, but alsot to prevent
>                confusions such as attempts to receive allocations from an
>RIR
>                outside their region. The five RIRs should facilitate
>bottom-up
>                discussions, which should be well coordinated under the
>                leaderships of ICANN ASO and NRO.
>
>
>     (2) Some blocks to be left:
>
>                It is not practical to consider that IPv4 address blocks can
>be
>                allocated to the last piece. It is expected to cause
>confusions
>                if one  party can receive an allocation while the other has
>to
>                give up, just with a touch of a difference. The best
>solution
>                to avoid such confusion is to set in advance, a date in
>which
>                one is able to receive  an allocation if requests are
>submitted
>                before this timeline.
>                
>                Furthermore, there are few cases where allocations or
>                assignments of IPv4 address space become absolutely
>necessary
>                in the future. For      example, requirements to start a
>translator
>                service between IPv4 and IPv6 networks should be supported,
>and
>                there may be some requirements  in the future that are
>beyond
>                our imagination at this current moment.
>        
>                As such, a date to stop allocations under the current policy
>                should  be set/defined so that certain number of IPv4
>address
>                blocks will be kept as stocks instead of allocating all
>blocks
>                without remains.
>
>
>        (3) Maintaining current practices until the last moment :
>
>                Allocations should be made based on the current policy until
>the
>                time to terminate allocations. As the IPv4 Internet has now
>                developed into a social infrastructure supporting large
>number
>                of businesses, making large changes in the current policy
>                towards conservation within the next one or two years will
>lead
>                to large-scale confusions, and difficult in the reality.
>
>
>        (4) Separate discussion from "Recycle" issue
>        
>                Recovering unused allocated/assigned address blocks is an
>                important measure, and in fact, it has already be discussed
>and
>                implemented in each RIR regions. This issue, however should
>be
>                considered separately from this proposal as recovery of a
>few
>                /8 blocks extends the lifetime of IPv4 for less than one
>year
>                while efforts for the recovery is expected to require
>                substantial time.
>
>
>4.2 Details of the proposal
>
>        This section provides an example of a proposal in case consensus is
>        reached on basic principles introduced in section 4.1.
>        
>        - Set the date for termination of allocations and the date of
>           announcement
>        
>           Set the date to terminate allocations as a general rule, and
>           announce it a certain period in advance. Define the date of
>           announcement as "A-date" and the date to terminate allocations
>           as "T-date". The two dates will be set as follows:
>        
>        
>                   A-date (Date of Announcement):
>                        
>                   - The day in which the IANA pool becomes less than 30*/8
>                        
>                   - RIRs must announce "T-date" on this day, which is
>defined
>                        later
>                        
>                        (*) There will be no changes in the policy on
>A-date
>
>                        
>                   T-date(Date of Termination):
>                        
>                   - Exactly two years after A-date
>                        
>                   - 10*/8 blocks should remain at T-date, and defined as
>two
>                        years after A-date, based on the current pace of
>                        allocations
>                                
>                   - It is however possible to move T-date forward at the
>point
>                        where address consumpution exceeds the projections
>during
>                        the course of two years
>                                        
>                        (*) new allocations/assignments from RIRs should
>terminate
>                             on T-date as a general rule. Allocations or
>assignments
>                             to "critical infrastructure" after T-date
>should be
>                             defined by a separate policy.
>                
>                
>                A-date is set in order to:
>                
>                - Allow some grace period and period for networks to be IPv6
>                  ready until the termination of allocations.
>                - Prevent unfairness among LIRs by clarifying the date, such
>                  as not being able to receive allocations by a small
>difference
>                  in timing.
>                
>                The rationale for setting A-date as "when IANA pool becomes
>less
>                than 30*/8" is as follows:
>                
>                        The rate of allocations from IANA to RIRs after 2000
>is as
>                        follows.
>                        
>                                2000 : 4*/8
>                                2001 : 6*/8
>                                2002 : 4*/8
>                                2003 : 5*/8
>                                2004 : 9*/8
>                                2005 : 13*/8
>                                2006 : 10*/8
>
>                        Approximately 10*/8 has been allocated annually
>after 2003,
>                        and the consumption is likely to accelerate with
>rise of the
>                        last minute demands. As it is better to keep minimum
>stocks
>                        of address pool at IANA, 30*/8 is set as the
>threshold
>                        value, and allocations should be terminated two
>years after
>                        it reaches the value, which ensures that IANA/RIRs
>secure
>                        the address space for allocations/assignments to
>critical
>                        infrastructure.
>
>
>4.3 Effect on APNIC members/NIRs
>
>        APNIC members are expected to concretely grasp the termination date
>        of allocations and take actions within their organization to prepare
>        for the event.
>        
>        NIRs will also terminate allocations to its LIRs in line with APNIC.
>        Therefore, NIRs will be required to sufficiently promote and keep
>        the     community informed on the date of termination of
>allocations,
>        just as it is expected of APNIC.
>
>
>*              sig-policy:  APNIC SIG on resource management policy           *
>_______________________________________________
>sig-policy mailing list
>sig-policy at lists.apnic.net
>http://mailman.apnic.net/mailman/listinfo/sig-policy

_______________________________________________
global-v6 mailing list
global-v6 at lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/global-v6

----- End forwarded message -----


Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  98999

SpaceNet AG                    Mail: netmaster at Space.Net
Joseph-Dollinger-Bogen 14      Tel : +49-89-32356-0
D- 80807 Muenchen              Fax : +49-89-32356-234