6BONE Pre-Qualification for Address Prefix Allocation (6PAPA)

[Bob Fink]

INTERNET-DRAFT                                          Bob Fink, ESnet
January 10, 2000

          6BONE Pre-Qualification for Address Prefix Allocation (6PAPA)

                  <draft-ietf-ngtrans-6bone-6papa-01.txt>


Abstract

This memo describes how the 6bone may be used as a prequalification step
during the "bootstrap" phase of sub-TLA assignment by the Regional
Internet Registries (RIRs).


Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and
may be updated, replaced, or obsoleted by other documents at any time.  It
is inappropriate to use Internet-Drafts as reference material or to cite
them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet Draft expires July 10, 2000.


Acknowledgements

Ideas in this draft are, in part, contributions of various IETF working
groups, the Regional Internet Registries, participants of the 6bone
testbed, and the worldwide IPv6 community.


Contents

Status of this Memo..........................................

Acknowledgements.............................................

1.  Introduction.............................................

2.  6BONE Prequalification for sub-TLAs......................

3.  Security Considerations..................................

4.  Change Log...............................................

REFERENCES...................................................

AUTHOR'S ADDRESS.............................................


1. Introduction

This memo describes how the 6bone is used as a prequalification step
during the "bootstrap" phase of sub-TLA assignment by the Regional
Internet Registries (RIRs). It is based on the following points.

1.1 The 6bone community represented the world-wide IPv6 operational
networking community as of early 1999, including all existing IPv6
providers and users in the world, operating under the only IPv6 address
allocation and authority in place at that time, i.e., the 3FFE::/16 TLA
allocation to the 6bone, documented in [6BONE-TLA].

1.2 The 6bone uses a well defined top level address structure called a
pseudo-TLA (pTLA), documented in [PSEUDO], that is delegated from its
3FFE::/16 allocation, that all top level 6BONE IPv6 transit providers use.

1.3 The 6bone process for allocation of pTLA-s is well defined in section
7 of [HARDEN] and is well accepted by the 6bone community.

1.4 The 6bone community as a whole is willing to provide their knowledge,
experience and opinions as part of a process to help "bootstrap" the sub-
TLA address allocation process for the RIRs.


2. 6BONE Prequalification for sub-TLAs

2.1 A sub-TLA requestor (sTR) places a sub-TLA request with the
appropriate RIR, per the RIR's own sub-TLA procedures, indicating that
they intend to use 6bone prequalification.

2.2 The sTR follows the published process for becoming a pTLA as
documented in Section 7 of [HARDEN]. (Note that [HARDEN] specifies the
minimum time from first joining the 6bone as an end-site network to
becoming a pTLA as 3 months.) Those pTLA allocations in effect prior to
[HARDEN], or its predecessor RFC2546, are considered to have met all
requirements for becoming a pTLA. However, 2.3 still applies.

2.3 An sTR must have operated as a pTLA for at least 3 months, with at
least 3 active delegations under its pTLA (either lower level transits or
end-sites, or a mix of both), for the sTR to meet the 6bone experience
criterion (6EC).

2.4 A 6bone steering group (6SG), consisting of 3-5 persons established
by 6bone participant consensus, uses factual operational information and
other relevant experience of the sTR to determine if the 6EC has been met.
It is expected that the 6SG will respond within 30 days. It is up to the
RIR's own policies and procedures to determine what happens if this time
is not met.

2.5 After allocation of a sub-TLA to the sTR (by an RIR), the sTR may
optionally renumber from the 6bone pTLA prefix to the new sub-TLA prefix,
or continue to use their pTLA for multihoming purposes. If the pTLA space
becomes over subscribed, the most likely networks to be asked to surrender
a pTLA would be those holding production TLA/sub-TLA prefix space.
Given the large size of the pTLA space this is not considered likely to
ever happen.


3.  Security Considerations

There are no security considerations of this document as it only specifies
a process of recommendations made to IPv6 Address Registries for
prequalification for production IPv6 Address Prefix allocations.


4.  Change Log

Changes since version -00 of the draft:

Various rewordings for clarity.

Replace [RFC 2546] references with new HARDEN specification now
approved as Informational RFC.

Notes that pTLAs prior to [HARDEN] and RFC 2546 are legitimate pTLAs,
though still 3 months of oeprating experience with at leasts 3
delegations.

Removal of the previous 2.2 requirement that the sTR notifies the 6bone
list of intent to use the 6PP.

In previous 2.4 (now 2.3) clarifies that it is 6bone experience criteria
that is being met by the sTR for operating for 3 months.

The new 2.4 specifies a 6SG maximum response interval of 30 days, with the
RIR being responsible for deciding what to do when this time is exceeded.

Removal of any mention or implication that the 6bone community us stating
that an sTR is qualified for a sub-TLA allocation.

Removal of previous 2.6 regarding time out issues.

Removal of section 3. Only meaningful removal was regarding some pTLA-s
not qualifying for this process due to the nature of there network.
This had been regarded as unfair and unreasonable and there was general
agreement to remove this.


REFERENCES

[KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.

[6BONE-TLA] R. Hinden, R. Fink, J. Postel, "IPv6 Testing Address
Allocation", RFC 2471, December 1998.

[PSEUDO] R. Fink, "6bone pTLA & pNLA Formats", see <http://6bone.net>,
January, 2000.

[HARDEN] R. Rockell, R. Fink, "6Bone Backbone Routing Guidelines",
RFC xxxx, December 1999. Replaces RFC 2546.


AUTHOR'S ADDRESS

         Bob Fink, ESnet
         Lawrence Berkeley National Lab
         MS 50A-3111
         1 Cyclotron Road
         Berkeley, CA 94720
         USA

         phone: +1 510 486 5692
         fax:   +1 510 486 4790
         email: fink@es.net

-end