Proposal for Transfer of 6bone Address Management Responsibilities to RIRs

[Member Services]

It has been proposed that the management of the 6bone 3FFE::/16 
address space be transferred to the Regional Internet Registries
(RIRs).  More information about the 6bone can be obtained at
http://www.6bone.net/.  

At a recent 6bone meeting, Bob Fink made a proposal for this 
management transfer.  A copy of the presentation slides are 
available at http://www.6bone.net/ngtrans/minutes/default.htm.  
These presentation slides were based on the text, "Policies for 
transfer of 6bone address management responsibilities to RIRs," 
provided below.

Please send your comments about this proposal to the ARIN public 
policy mailing list (ppml at arin.net).  The 6bone will be conducting 
a similar review within their community and we will do our best to 
correlate and summarize the collective responses, issues, and 
concerns, made in regard to this proposal.  This review process 
will end on December 31, 2002.

Best Regards,

Member Services
American Registry for Internet Numbers (ARIN)


### * ###

Policies for transfer of 6bone address management responsibilities to RIRs


Version: 20 August 2002


1. Introduction

6bone was established in 1996 as a continuing IPv6 test bed with the 
original purpose of testing of standards and implementations, and the more 
current focus on testing of transition and operational procedures, as well 
as application conversion.  It provides an opportunity for those wanting 
early experience and/or needing to experiment with IPv6, with a minimum of 
startup complexity, particularly in terms of address management policies, 
and at minimal cost.  It also provides an open peer process for 
information, hookup help, and support, with strong ties to the IETF process 
as well as to the operational community.

To date, 6bone address space has been allocated and registered in an 
informal process quite separate from the existing Regional Internet 
Registry system. The purpose of this proposal is to establish a long term 
model that provides for a more "official" home for 6bone address space 
management within the established Internet administrative structures. At 
the same time, the proposal recognizes that 6bone's most important 
functions as an accessible and informal test bed network must be maintained.

This document proposes the transfer of responsibility for administration of 
6bone address space (3ffe::/16) to the Regional Internet Address Registries 
(RIRs). It describes a set of policies and procedures for this transfer, 
and for the ongoing administration of 6bone address space within the RIR 
framework.

It should be noted that the ongoing operation of the 6bone, and policies 
related to it, are still the purview of the 6bone community itself. For 
example, 6bone network compliance with the 6bone routing guidelines is a 
matter for the community itself to resolve, typically by mail lists.

It is also important to continue the strongly volunteer efforts of the 
6bone, both to make it as easy and friendly as possible for individuals, 
sites and networks to experiment and learn about IPv6, but also to keep the 
process streamlined and cost-effective.

2. Definitions

a)	"6bone" and "6bone community", as it appears in section 3 below, means 
6bone organizations and individuals including the RIRs, "6bone members" 
(see below), and those participating in the 6bone mail list.

b)	6bone members are defined as entities which are approved for address 
space allocation by the 6bone community in accordance with 6bone policies, 
and who agree to be bound by those policies and the policies stated below.

c)	6bone allocations are allocations of 6bone address space which are held 
by 6bone members, or made to 6bone members in accordance with these policies.

d)	6bone address space is defined as IPv6 address space within the 
3ffe::/16 address block.

3. Policies

3.1 General

a)	In consultation with 6bone, RIRs will implement a common set of policies 
applying specifically to 6bone allocations. This will follow the current 
RFC2772, "6Bone Backbone Routing Guidelines" and/or successor documents 
resulting as an evolution of conversations in the 6bone community and the 
RIRs.;

b)	6bone members will be served by respective RIR in their region, for 
"6bone Address Services" including 6bone address allocation, database 
registration and  maintenance, and ip6.arpa registration (as described below);

c)	In order to receive 6bone address services from an RIR as described 
here, each 6bone member must "join" that RIR, that is, enter into the 
appropriate membership or services agreement with the RIR.

d)	RIR fees will be waived for 6bone address services provided by RIRs to 
6bone members (but not for other services 6bone members may require), until 
1 year after this agreement starts.  After this time each RIR may charge an 
administration fee to cover each allocation made.  This fee simply covers 
registration and maintenance, rather than the full allocation process for 
standard RIR members. This administration fee should be as low as possible 
as these requests do not have to undergo the same evaluation process as 
those requested in the normal policy environment.

e)	Organizations may receive 6bone address services from the RIR only on 
approval by 6bone, and in accordance with these policies;

f)	6bone members will have the option to receive other services from an RIR 
(including allocation of production IPv6 address space), by following the 
policy, process and procedures in place at the time of application for 
those services.

g)	Continuing compliance with 6bone policies, and with the policies defined 
here, will be verified by 6bone at least every 2 years;

3.2 6bone Address Services

a)	6bone Address Services include allocation of 6bone address space, 
registration and maintenance of database records relating to that address 
space, and registration of ip6.arpa records;

b)	6bone address space allocations will be made from 3ffe::/16 and only /32 
prefixes will be allocated. There will be exceptions for unusual and new 
proposals per joint RIR and 6bone review and approval. A relevant example 
of this is one or more new strategies such as geographic or metro addressing;

c)	No additional 6-bone address space will be allocated to any 6bone member 
(therefore no provision will be made for aggregation of multiple 
allocations, reservations etc);
d)	6bone address services will be provided strictly for experimental, 
non-commercial use;

e)	Allocations will be made on the clear and stated understanding that the 
prefix 3ffe::/16 has a limited lifetime. The dates for the termination of 
allocation from the prefix and the expiration of the prefix will be 
determined at a future date.  The RIRs will not participate in these 
determinations.

f)	6bone address space will be returned to the RIR when no longer in use, 
when reclaimed due to non-compliance with 6bone or RIR policies, or when 
3ffe: space is finally withdrawn.

g)	Registration of 6bone address space within the ip6.int zone is not 
covered by this policy, and is at option of 6bone member;

h)	Registration of 6bone sites, maintainers, persons and address space 
within the existing consolidated 6bone registry is not covered by this 
policy, and is at option of 6bone and its current policies.

3.3 Transfer of existing 6bone members

a)	Responsibility for existing 6bone members in respect of services 
described here will be transferred from 6bone to the respective RIR, at the 
option of those members individually, on entering into the appropriate 
agreement with the RIR;

b)	On joining the RIR, 6bone address registration records for the member 
concerned will be transferred from 6bone registry to the respective RIR 
database,;

c)	On joining the RIR, 6bone members may establish ip6.arpa delegation 
records in accordance with applicable RIR procedures;

d)	Legacy holders will use RIR administrative procedures for management of 
their records;

e)	There will be a sunset (2 years?) on existing 6bone members not 
transferring to RIR administrative procedures, after which their address 
allocation will be revoked.

-end