[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Announcing 2003::/16 during tests of "shipworm"
At 08:37 AM 12/7/2001 -0500, Robert J. Rockell wrote:
>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):
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 <[email protected]>
>To: Bob Fink <[email protected]>
>Cc: Bert Wijnen <[email protected]>,
> IETF Secretariat <[email protected]>,
> Alain Durand <[email protected]>, Tony Hain <[email protected]>,
> NGtrans List <[email protected]>
>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.
>From: Randy Bush <[email protected]>
>To: Christian Huitema <[email protected]>
>Cc: Alain Durand <[email protected]>,
> Tony Hain <[email protected]>,
> Bob Fink <[email protected]>,
> Bert Wijnen <[email protected]>
>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.
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.