pTLA request for DREN (www.v6.dren.net) - review closes 9 June 2001

Bob Fink fink@es.net
Sat, 26 May 2001 10:46:32 -0700


6bone Folk,

DREN (the Defense Research and Engineering Network) (www.v6.dren.net) has 
requested a pTLA allocation. This is a slightly different situation in that 
DREN has established their peerings using a 6to4 peering, though otherwise 
they are normal BGP4+ peerings. I asked Ron Broersma of DREN to explain a 
little bit about this and about DREN in addition to their application. I've 
included this below.

The open review period for this will close 9 June 2001. Please send your 
comments to me or the list.


Thanks,

Bob

===

>Date: Fri, 25 May 2001 09:02:58 -0700
>From: "Ron Broersma" <ron@spawar.navy.mil>
>To: Bob Fink <fink@es.net>
>Subject: Re: pTLA request for DREN
>
>Bob,
>
>In response to your questions.
>
>DREN is the Defense Research and Engineering Network.   It is the network that
>provides network services and connectivity to the DoD research and engineering
>communities, including 70 large DoD installations, and also services various
>consortium networks and other federal network communities.  DREN operates 
>a native
>IPv6 network as one of its services.
>
>DREN is using a 6to4 prefix because this allowed us to not only test the 6to4
>mechanisms on a wide area network, but also allowed the network to be 
>immediately
>operational when it was initially installed, while waiting for a more 
>permanent
>address allocation.  We still established BGP4+ peering sessions with 
>other ISPs
>either natively or via tunnels over IPv4, receive full routing from multiple
>sources, operate default-free, run a full-mesh I-BGP internally, and 
>announce our
>prefix to the E-BGP peers for distribution within their own AS.  The only 
>negative
>is the non-optimal routing on the return path for nets you don't peer with
>directly, but that's OK for a temporary solution.
>
>--Ron
> > At 12:35 AM 5/24/2001 -0700, Ron Broersma wrote:
> > >   1. The pTLA Applicant must have a minimum of three (3) months
> > >       qualifying experience as a 6Bone end-site or pNLA transit.  During
> > >
> > >       the entire qualifying period the Applicant must be operationally
> > >       providing the following:
> > >
> > >       This pTLA request is for a new backbone that went operational
> > >       in February.
> > >
> > >       a. Fully maintained, up to date, 6Bone Registry entries for their
> > >          ipv6-site inet6num, mntner, and person objects, including each
> > >          tunnel that the Applicant has.
> > >
> > >          ipv6-site:     DREN
> > >          inet6num:      2002:8031:C003::/48
> > >          mntner:        MNT-DREN
> > >          persons - RLB1-6BONE, TGK7, RAM1-6BONE
> > >          tunnels are registered in ipv6-site object.
> > >
> > >       b. Fully maintained, and reliable, BGP4+ peering and connectivity
> > >          between the Applicant's boundary router and the appropriate
> > >          connection point into the 6Bone. This router must be IPv6
> > >          pingable. This criteria is judged by members of the 6Bone
> > >          Operations Group at the time of the Applicant's pTLA request.
> > >
> > >          Example:  nrl-dc.v6.dren.net -> sl-bb1-6bone.sprintlink.net
> > >                    This router: 3FFE:2900:B:8::2
> > >
> > >       c. Fully maintained DNS forward (AAAA) and reverse (ip6.int)
> > >          entries for the Applicant's router(s) and at least one host
> > >          system.
> > >
> > >          All routers (including every IPv6 interface) are registered in
> > >          both directions. Examples for verification:
> > >                 router: sscsd.v6.dren.net
> > >                 host:   www.v6.dren.net
> > >
> > >       d. A fully maintained, and reliable, IPv6-accessible system
> > >          providing, at a mimimum, one or more web pages, describing the
> > >          Applicant's IPv6 services.  This server must be IPv6 pingable.
> > >
> > >          www.v6.dren.net
> > >
> > >    2. The pTLA Applicant MUST have the ability and intent to provide
> > >       "production-quality" 6Bone backbone service. Applicants must
> > >       provide a statement and information in support of this claim.
> > >       This MUST include the following:
> > >
> > >       a. A support staff of two persons minimum, three preferable, with
> > >          person attributes registered for each in the ipv6-site object
> > >          for the pTLA applicant.
> > >
> > >          RLB1-6BONE
> > >          TGK7
> > >          RAM1-6BONE
> > >
> > >       b. A common mailbox for support contact purposes that all support
> > >          staff have acess to, pointed to with a notify attribute in the
> > >          ipv6-site object for the pTLA Applicant.
> > >
> > >          noc@v6.dren.net
> > >
> > >    3. The pTLA Applicant MUST have a potential "user community" that
> > >       would be served by its becoming a pTLA, e.g., the Applicant is a
> > >       major provider of Internet service in a region, country, or focus
> > >       of interest. Applicant must provide a statement and information in
> > >
> > >       support this claim.
> > >
> > >       DREN is already an established ISP for the DoD research community.
> > >
> > >       The pTLA would service this community, as well as other existing
> > >       subscribers.
> > >
> > >    4. The pTLA Applicant MUST commit to abide by the current 6Bone
> > >       operational rules and policies as they exist at time of its
> > >       application, and agree to abide by future 6Bone backbone
> > >       operational rules and policies as they evolve by consensus of the
> > >       6Bone backbone and user community.
> > >
> > >       Concur.
-end