[6bone] Re: routing concern

[Robert J. Rockell]

perhaps a good compromise here is to take steps towards at least base-lining
the 6bone with decent inter-domain routing rules? The first two things that
stick out that hinder the 6bone from being a viable testbed (assuming a
sutiable definition for Testbed is: A network that emulates what the real
world (might) look like, so tests can be performed):

-filtering (popular one on this mailing list)
-less transit

Right now, it seems like the default for pTLA's is to give transit to each
other.  In the ipv4 world (and I don't see how this changes in IPv6)
normally, big networks have one or a few transit providers, but then only
peer with non-transit to all other networks.  Today, it looks like transit
is the de-factor for pTLA---pTLA peering.  If we cut this down, it allows us
to:

1. better optimize routing, because we can work out who has the
best/widest-reaching pTLA network, and get transit from that network (avoid
long tunnels, not following geographic topology, etc..).

2. filters more strongly (if you only receive one prefix from a peer, it is
much easier to filter strongly than if you filter the whole table
explicitly).

The concept of 'less transit' I don't think has been addressed here yet, but
I think it is a suitable pursuit for current pTLA network operators to look
at, as I think it would help with scaling, filtering, etc... I don't need 20
paths to every pTLA, especially if I'm directly peered with that pTLA.

Thanks
Rob Rockell
SprintLink International
(+1) 703-689-6322
Sprint IP Services
-----------------------------------------------------------------------

On Wed, 31 Jul 2002, John Fraizer wrote:

->
->On Wed, 31 Jul 2002, Ronald van der Pol wrote:
->
->> On Tue, Jul 30, 2002 at 11:13:36 -0700, Michel Py wrote:
->>
->> > As I said before, the 6bone is the right place for this. Has anyone been
->> > hurt? Anyone lost money? The lessons we collectively learn each time
->> > someone messes up a route are far more valuable than the consequences of
->> > messing up the route.
->>
->> Is it time to start making a clear distinction between IPv6 production
->> and IPv6 experimentation/learning? I think today the 6bone is used for
->> both.
->>
->> Many use IPv6 for their daily work *). We *need* a stable network for
->> that.  If we don't do that we risk scaring people away from IPv6. Most
->> OSes support IPv6 nowadays. When an enduser starts using IPv6 for the
->> first time and she notices all kinds of networking problems, many will
->> think: "OK, let's turn off IPv6. It does not work."
->>
->> The RIR prefixes are meant for IPv6 production. So, I think they should
->> not be used on the 6bone. The 6bone should only be used for experiments
->> and possibly learning. And on the other hand, I think production services
->> should not use 6bone prefixes, but RIR prefixes.
->>
->> 	rvdp
->
->If you don't want to see RIR space on your router Ronald, you can filter
->it.  I _strongly_ disagree with having a hard seperation of production v6
->and 6bone though.  There already exists seperation.  Production services
->on production prefixes.  6bone experiments on 6bone prefixes.
->
->Do you really want to create an island out of the production v6
->network?  Do you want folks on production v6 address space to not be able
->to reach 6bone prefixes?
->
->We're not asking people to stop experimenting.  We're asking them to do so
->wisely.  As for scaring people away from v6, I don't see it.  As
->confounded as it is, the 6bone is more robust then the initial v4
->network.
->
->> *) I frequently use ftp, cvs and http over IPv6 to sites far away in
->> the internet. Too often, there are routing problems and IPv6 traffic
->> is blackholed (routing loops, etc). Most application time out and try
->> IPv4. But this means annoying delays. Many of these problems occur
->> because people are running production services over the 6bone.
->
->The last time I checked, the 6bone was an adhock network of folks running
->(mostly) v6-in-v4 tunnels between each other to establish v6 (notice I
->don't make distinction between 3ffe::/16 and 2001::/16 here) connectivity
->in the absence of NATIVE v6 connections.  Granted, there are some native
->v6 links.  That is great.  The *majority* of links are v6-in-v4 tunnels
->though.
->
->If you're complaining about people running production services on 6bone
->PREFIXES, perhaps they haven't gotten around to getting their RIR space
->yet.  Perhaps they haven't made the obvious distinction between their v6
->and v4 webservers. (Hint: www.[domain].com = v4, www.ipv6.[domain[.com =
->v6)  This gives the USER the choice, based on the URL they type in.
->
->I honestly don't see a problem with the two (6bone and production) being
->interweaved.  Had the aggregation mistake been made on a 3ffe::/16 prefix,
->it wouldn't have been as big of a deal.  The fact that it aggregated the
->entire ARIN RIR *production* v6 space was the problem.
->
->
->
->---
->John Fraizer              | High-Security Datacenter Services |
->EnterZone, Inc            | Dedicated circuits 64k - 155M OC3 |
->http://www.enterzone.net/ | Virtual, Dedicated, Colocation    |
->
->