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

[Robert J. Rockell]

Sprint is now giving transit to 2003::/16.  Thanks for the clarification,
Bob.     It is announced to all 3FFE::/16 addressed peers.


Thanks
Rob Rockell
Principal Engineer
SprintLink Europe/Asia
(+1) 703-689-6322
Sprint IP Services : Thinking outside the 435 box
-----------------------------------------------------------------------

On Fri, 7 Dec 2001, Bob Fink wrote:

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