APNIC Home APNIC Home
Info & FAQ |  Resource services |  Training |  Meetings |  Membership |  Documents |  Whois & Search |  Internet community

You're here:  Home  Mailing Lists sig-policy 


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sig-policy] prop-050-v002: IPv4 address transfers




Philip Smith wrote:
I certainly believe that this policy proposal needs to be implemented if APNIC is to remain in its position of registering the use of IPv4 address resources. As we all know, IPv4 address space is already "bought" and "sold" commercially, so this is a first step at actually legitimising these transfers. Transfers without records of these transfers makes it harder for ISPs to trust prefix announcements.

However, I feel the principle of the policy needs to go further:

- incorporate NIRs, as NIRs are *not* independent resource registries but are part of the APNIC family

- allow LIR members of other RIRs to participate too.

But one small step at a time; I feel this proposal is the correct first step forward...

One aspect of the amended policy which may make it easier to incorporate a wider community of participation in such a framework of recognition of address transfers is the following text:



        In order to preserve aggregation capabilities the transfer
        recipient may notify APNIC that the transferred address may be
        returned to the unallocated APNIC address pool, and a different
        address of the same size may be registered to the recipient of
        the transfer. This option would be available to the recipient of
        the transferred address, at the discretion of the recipient.



This would allow, for example, an address prefix to be returned to one registry point and an equivalent prefix assigned from another registry point without having to make a series of 'upstream' changes to move the actual address across registry points, whether they may be NIRs, LIRs or other RIRs.

It assumes, however, that there is a certain amount of residual 'liquidity' in the registry pools to achieve this, which is not something which can be assured right now.

regards,

   Geoff