Tony Tauber wrote:

On Mon, 8 Jul 2002, Rob Thomas wrote:

...

Hi, John.

...

192.88.99.0/24 which is the 6to4 anycast network. Do we really want to be filtering that prefix?

Good question. I'm re-reading RFC 3068 now, and the RFC appears to allow for the advertisement of this prefix into the global table. I'm wondering if this is wise, however. It seems this prefix would best be used internally. What do others think?

Thanks, Rob.

I believe the idea is that it typically comes from outside one's domain because it's supposed to allow edge islands of IPv6 to find the mainland. If you had a connection to the mainland under your control, you wouldn't need this trick to get there.

At least that's my understanding.

Tony

Close. The prefix should be advertised to the customers of the network which has the interconnect. If those customers are other SPs, the downstream will receive it from outside, and should advertise it to their customers. If a SP chooses to provide the interconnect service, it may still want to receive that prefix from outside as a backup. The point is that it is a well-known prefix that allows end customers to deploy IPv6 even if their direct SP chooses not to support it on their timeframe. It is designed on the assumption that the first hop SP is doing nothing about IPv6 deployment, and that includes not filtering the prefix. It would be wise to continue announcing it even after the SP starts announcing native IPv6 to customers because there will be some islands out there still, and it will be more efficient for the endpoints to directly tunnel over IPv4 than to run it through a central gateway service in each SP. Clearly each origin AS announcing the prefix will want to limit their exposure to their customers, but SPs without an interconnect should not have a problem accepting it. Tony