Announcing 2003::/16 during tests of "shipworm"

[Bob Fink]

At 08:37 AM 12/7/2001 -0500, Robert J. Rockell wrote:
>6bone=testbed
>
>testbed=announce routes that allow people to Test.
>
>I see no reason to not allow *ANY* prefix that has a legit purpose for
>testing on the 6bone.  This should in no way break any existing asignments.

I do agree with this. The 6bone is a test network, and as such would not be 
doing a proper job if we didn't allow new ideas (and prefixes) to be used 
for testing, as long as they don't mess up others (which Rob covers below).

A point that should be re-emphasized about the 6bone is that it does have a 
need to interconnect to the "production" IPv6 Internet. A 
non-interconnected set of networks is not the Internet as we all know and 
love it, and the v6 Internet is no exception.

Many/most/all of the open v6 peering points around the world do, in fact, 
connect 3FFE and 2001 prefix-using networks together. Some of these 
networks even have both 3FFE and 2001 prefixes allocated to them. We 
continue to encourage such peerings and trust that properly managed and 
operated peerings protect bad things from happening (which is what RFC2772 
is about, but read on below).


>Unless I hear something from Working-Group chairs, I will be appending this
>prefix to my filters today.
>P.S. If any of you have this route in your table now, you aren't abiding by
>rfc2772 for filtering anyhow, so I don't see where the room to complain
>about it exists.  If you filter strictly, you would not see this route
>in your RIB...

RFC2772 is the 6bone's current operational guidelines, both for routing and 
overall participation. Rob and a few others of us are now doing a rewrite 
to bring it up to date, but it is still in force and very relevant.

As for the filtering rules in RFC2772, I presume Rob refers to the 
parenthetical note in RFC2772 3.1:

"(Also, it is each pTLA, pNLA, and end-site's responsibility to not only 
filter their own BGP4+ sessions appropriately to peers, but to filter 
routes coming from peers as well, and to only allow those routes that fit 
the aggregation model, and do not cause operational problems)."

The reader should also look at the rest of section 3, as well as sections 4 
and 9, for more general guidance for routing policy and other filtering.


As for SHIPWORM's status in ngtrans, you should read the ngtrans project 
status page (I do keep it quite up to date):

<http://www.6bone.net/ngtrans/ngtrans_project-status.html#SHIPWORM>

which currently states:

shipworm-02 published 26Sep01, last call for forwarding closes 12Oct01
shipworm-03 published 16Oct01 to answer last call comments
             forwarded to IESG 18Oct01
             IESG evaluating nat traversal issues before proceeding

The last communications on this with Randy Bush, our AD, are:

>From: Randy Bush <randy@psg.com>
>To: Bob Fink <fink@es.net>
>Cc: Bert Wijnen <bwijnen@lucent.com>,
>         IETF Secretariat <ietf-secretariat@ietf.org>,
>         Alain Durand <Alain.Durand@sun.com>, Tony Hain <tony@tndh.net>,
>         NGtrans List <ngtrans@sunroof.eng.sun.com>
>Subject: (ngtrans) Re: forwarding SHIPWORM for PS
>Date: Thu, 18 Oct 2001 23:11:40 -0700
>
> > SHIPWORM-02 finished ngtrans WG last call with comments that were resolved
> > in the new -03 draft:
> >
> > <http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-shipworm-03.txt>
> >
> > Please process this draft as a candidate for PS.
>
>the iab has raised a general architectural issue regarding nat traversal
>that has clear relevance to this draft, midcom, and so forth.  i am trying
>to understand it more before progressing.  please stay tuned.
>
>randy

and:

>From: Randy Bush <randy@psg.com>
>To: Christian Huitema <huitema@windows.microsoft.com>
>Cc: Alain Durand <Alain.Durand@sun.com>,
>     Tony Hain <tony@tndh.net>,
>     Bob Fink <fink@es.net>,
>     Bert Wijnen <bwijnen@lucent.com>
>Subject: Re: shipworm progress?
>Date: Thu, 08 Nov 2001 13:43:15 -0800
>
> > When can we expect the IESG to issue a last call?
>
>no sooner than the architectural issues that were raised with the midcom
>etc. work are resolved.
>
>randy


We, the ngtrans chairs, do want SHIPWORM to progress into production, but a 
Shipworm IPv6 service prefix
is not likely to be assigned by IANA until the IESG moves the draft forward 
(Randy can correct me if I am wrong). Meanwhile, testing is needed and 
underway. Any choice of interim prefix is almost certainly likely to be 
different than one assigned for production, so I don't particularly care 
what is used.

If a 3FFE-based prefix is temporarily requested, I would support allocating 
it for further testing, but don't think it matters at this stage given the 
test use of 2003 for this is already underway.


Thanks,

Bob