6bone Prequalification for Sub-TLA assignment

[Bob Fink]

6bone Folk, 

At the recent Minneapolis IETF meetings, the three RIR registries (APNIC,
ARIN and RIPE-NCC) had meetings with various groups about their recent
draft proposal for policies regarding the assignment of production IPv6
Sub-TLA address prefixes. One of the most difficult aspects of their policy
(for them and for the IPv6 community) is to figure out how to go safely
between the two extremes of either giving Sub-TLAs away too easily, or
making it too difficult to get them.

If Sub-TLAs are given away too easily, they will be encouraging non-ipv6
providers to get theirs now, i.e., the land rush model which could easily
fill up the TLA/Sub-TLA space with networks, sites, and organizations that
simply want to make sure they have a TLA/Sub-TLA, even if they don't need
one now or really qualify (i.e., they have no intent on putting up IPv6
service and/or are simply not higher level transits).

Alternatively, if Sub-TLAs are too hard to get, especially in the early
days of IPv6 deployment, it will discourage providers from putting up IPv6
service, may give the impression that IPv6 doesn't help the address space
problem at all, thus greatly impeding the progress of IPv6 deployment and
transition, and even pose a legal risk to the registries.

During the meetings and discussions with the registries during the IETF
week, the idea of potentially using the 6bone as some sort of
prequalification for getting Sub-TLAs from the RIRs was proposed. This
could be especially useful during the "bootstrap" phase of IPv6 deployment
and address assignement (say 6 months to 24 months max). This idea was well
received by the RIRs, the IAB, the IPv6 co-chairs and various folk in the
IPv6 community. Thus the idea was pursued with a first draft reviewed by
the IAB, the RIRs and the IPv6 co-chairs. Now it is time for getting
comments from the 6bone community, which is the purpose of this email.

An overview of the idea is that a network wanting a Sub-TLA would go
through the process of joining the 6bone to become a pTLA (for which rules
and procedures are in place, and soon to be reworked based on the 6bone
hardening effort now underway), and after spending 3 months as a pTLA would
ask for a "fitness report" from the 6bone community (actually a small
oversight group) to be made to the relevant RIR so that a Sub-TLA could be
assigned (thought it will still be the RIR making the actual decision and
assignment).

Note that the RIRs will soon reissue a draft incorporating other ideas and
comments from various sources, and will continue to have Sub-TLA
prequalification criteria independent of the ideas presented here. Also
note that the RIRs will still be the folk in charge of deciding who gets
TLA/Sub-TLAs. Our processes, if adopted, will only be advisory to the RIRs.

So, please review this carefully and send your comments to the full list
above (unless you have some reason to say something in private to someone!).


This will be open for discussion until 19 April '99, at which time the IAB,
RIRs and IPv6 co-chairs will decide whether to move forward on an agreement
about this or not, based on comments received. 


Thanks,

Bob

------------------
6bone Prequalification for Sub-TLA Assignment - draft 2, April 4, 1999 -
Bob Fink

The following is a draft to describe how the 6bone might be 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 facts:

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

F2. the 6bone has a well defined address structure underneath the RFC 2471
allocation for high-level (top tier) transit service providers, know 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. The pTLA structure is modeled on the
TLA structure and serves as a proving/testing ground for those structures. 

F3. the 6bone process for becoming a Pseudo-TLA (pTLA) is well defined and
accepted by the 6bone community. See
<http://www.6bone.net/6bone-routing-practice.htm> Section 7 for Guidelines
for 6Bone pTLA sites. It has just been made Informational RFC 2546.

F4. 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 (sTLA) address allocation process for the RIRs.

===
6bone Prequalification for Sub-TLAs 

S1. the sTLA requestor (sTR) places their Sub-TLA request with the
appropriate RIR and declares that they intend to use the 6bone
prequalification process (6PP).

S2. the sTR (and the RIR?) notifies the 6bone list of their intent to use
the 6PP.

S3. the sTR follows the published process for becoming a pTLA (This will
change by the end of the OSLO IETF meetings as the 6bone hardening process
is approved by the NGtrans 6bone community). At the present time this
process is documented by [RFC 2546] Section 7. This process currently
requires 2-3 months minimum, based on this current practice, from the time
of first joining the 6bone as a end-site network.

S4. after the sTR has been approved as a pTLA, and operating as a pTLA for
3 months with at least y customers (either lower level transits or
end-sites) (recommend 3 customers), 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).

S5. a 6bone steering group (consisting of 3-5 persons established by 6bone
participant consensus) prepares a short 6bone fitness report report (6FR)
based on input received from 6bone participants (note this means members of
pTLAs, pNLAs or end-sites organizations, not just mailing list subscribers)
and factual information of compliance with established pTLA rules extant at
the time (currently RFC 2546) and submits this report (the 6FR) to the
appropriate regsitry (will need a well established contact point for the
three IRRs).

S6. if after the minimum time for the steps above, plus 1 (2?) month(s),
the sTR may protest to the appropriate RIR of non-responsiveness and revert
to another qualification process per RIR rules (unrelated to the 6PP).

S7. after assignment of an sTLA to the sTR (by the RIR), the sTR may
optionally renumber from the 6bone pTLA prefeix to the sTLA 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 number space.

===
Misc. Notes:

N1. 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 become a pTLA.

N2. the current RFC 2546 doc does not specify a prequalification time as a
pNLA or end-site 6bone site prior to requesting a pTLA, so it is
recommended that a minimum of 2 months be specified (prior to the new rules
being published after Oslo).

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

N4. we need a way to handle existing pTLA sites that should not really have
an sTLA as they are not production networks, rather they were created to
"bootstrap" the 6bone or help a specific testing user community. This might
include sites like INNER, TELEBIT, VIAGENIE, CISCO, NRL, UO, 3COM, MERIT,
BT-LABS. Note that DIGITAL (now COMPAQ) is different in that they are
acting as a real IPv6 exchange thus have not been included in the previous
list. It is doubtful that these site would ask, but if they did it would be
unlikely they could get a positive 6PP Report. So maybe the problem should
be ignored and let the 6bone community police itself on this.

N5. clearly this process will be none too quick between the time to get it
firmed up and agreed to and the inherent time built into the process as
described above. Thus it may get poor support if the revised RIR draft
offers a reasonable alternative (of course that's why I noted this was a
voluntary path for sTRs to take). On this we will have to see what the RIRs
do in their next draft.

N6. there may be a liability exposure of the IETF with this process, given
the 6bone relationship to the IETF. This need not be covered here, but
everyone should be aware of the issue.


Things forgotten !!?? :-) Speak up!

-end