One document matched: draft-ietf-ngtrans-6bone-6papa-00.txt

INTERNET-DRAFT                                          Bob Fink, ESnet
August 23, 1999

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

                 <draft-ietf-ngtrans-6bone-6papa-00.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 February 23, 2000.

Acknowledgements

Ideas in this draft are, in part, contributions of the Regional Internet
Registries, participants of the 6bone testbed and members of the ngtrans
working group.

Contents

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

1.  Introduction.............................................    3

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

3.  Misc. Notes.............. .... .... .... ................    4

4.  Security Considerations..................................    4

5.  Change Log...............................................    5

REFERENCES...................................................    5

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

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 predicated on the following points.

1.1 The 6bone community represents 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
allocation to the 6bone under RFC 2471 ("IPv6 Testing Address Allocation")
<ftp://ftp.isi.edu/in-notes/rfc2471.txt>.

1.2 The 6bone has a well defined address structure underneath the RFC 2471
allocation for high-level (top tier) transit service providers, known as a
Pseudo-TLA (pTLA), that all the known top level IPv6 transit providers are
part of. See <http://www.6bone.net/6bone-testv2-addr-usage.html> for
documentation of the pTLA structure.

1.3 The 6bone process for becoming a Pseudo-TLA (pTLA) is well defined and
accepted by the 6bone community. See Informational RFC 2546
<ftp://ftp.isi.edu/in-notes/rfc2546.txt> Section 7 for current Guidelines
for 6Bone pTLA sites.

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

The following steps define the prequalification process using the 6bone.

2.1 The sub-TLA requestor (sTR) places their sub-TLA request with the
appropriate RIR and declares that they intend to use the 6bone
prequalification process (6PP). (Optional, based on RIR policy.)

2.2 The sTR notifies the 6bone list of their intent to use the 6PP. (This
assists the 6bone in establishing the time of first contact starting the
process, but does not constitute the actual start  of participation in the
6bone.)

2.3 The sTR follows the published process for becoming a pTLA. This
process is documented by [RFC 2546] Section 7. The minimum time from first
joining the 6bone as an end-site network to becoming a pTLA is set as  3
months.

2.4 After the sTR has been approved as a pTLA, and operating as a pTLA for
at least 3 months with at least 3 customers (either lower level transits
or end-sites), the pTR petitions the 6bone mailing list for support of its
request for a sub-TLA based on its performance as a pTLA, providing
relevant proof or statement of how and/or why they believe they have met
current 6bone backbone practices (currently as in RFC 2546).

2.5 A 6bone steering group (consisting of 3-5 persons established by 6bone
participant consensus) prepares a short 6bone fitness report (6FR) based
on input received from 6bone participants, and factual information of
compliance with established pTLA rules extant at the time (currently RFC
2546). It then submits the 6FR to the appropriate regsitry. Note that
6bone participant means members of pTLA, pNLA or end-site organizations,
not mailing list subscribers.

2.6 If after two months of petitioning the 6bone mailing list (2.4 above)
for support of its sub-TLA request with no response, the sTR may notify
the appropriate RIR of 6bone non-responsiveness and ask for the RIR to
proceed without a 6FR. (It is up to the RIR to decide what to do next,
including the decision that the sTR's experience with the 6bone qualifies
it for a sTLA allocation.)

2.7 After assignment of an sub-TLA to the sTR (by the RIR), the sTR may
optionally renumber from the 6bone pTLA prefeix to the sub-TLA prefix, or
continue use of their pTLA. If the pTLA space becomes over subscribed, the
most likely networks to be asked to surrender their pTLA would be those
holding production TLA/sub-TLA prefix space.

3. Misc. Notes

3.1 Currently the RFC 2546 doc is being reworked under the 6bone hardening
process now underway, which will almost certainly yield a stronger set of
rules on what it takes to operate as a pTLA.

3.2 The current RFC 2546 doc does not specify a prequalification time as a
pNLA or end-site 6bone site prior to requesting a pTLA. Thus these
prequalification rules have established the minimum time of 3 months from
first joining the 6bone as an end-site network to becoming a pTLA.

3.3 In S6. above, the total time from start of the 6PP until a protest
could be made to the RIR, would be in the 8 months minimum (3 mos.while
becoming a pTLA, 3 mos. while a pTLA, plus 2 mos.).

3.4 Some existing pTLA sites should not be allocated a sub-TLA as they are
not production networks, rather they were created to "bootstrap" the 6bone
or help a specific testing user community. The decision on what pTLA may
or may not qualify for a sub-TLA is left to the process outlined above,
and the RIR processes for allocating sub-TLAs.

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

5.  CHANGE LOG

Changes since version -00 of the draft:

None yet.

REFERENCES

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

AUTHOR'S ADDRESS

        Bob Fink
        Lawrence Berkeley National Lab
        ESnet - 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