APNIC IPv6 transit exchange
gert at space.net
Tue Dec 4 21:44:22 CET 2007
On Wed, Dec 05, 2007 at 04:28:07AM +1000, Terry Manderson wrote:
> This really begs the question as when is considered a customer, a peer,
> or a transit in v6 space? I mean you can certainly intuit the state.
> (as contracts, and money exchange, are mostly non-existent and changes
> to the relationship happen without changes to any other mechanisms). In
> intuition good enough here? (I'm guessing on your reaction it isn't)
Well, it really depends on how prefixes are advertised and transited.
- if you give transit for someone (announce them to your upstreams),
they are a customer
- if someone is giving you a full table, they are an upstream
- by definition: if you accept a full table from someone, you do not
announce the resulting prefixes to someone else who considers you
to be a customer of them.
- a peer is someone that gives you "their routes and their customers",
but *not* full tables, and that you don't announce to your transit
In IPv4 land, this is very much tied to contracts and money, but in IPv6
land, this is normally not very hard to distinguish either.
... and this, exactly, is the problem that some networks have: they do
not properly classify the ASes they peer with, and announce everything
everywhere. And as a result, you end up seeing transit paths that take
very surprising routes.
> Is there any well defined work in the community to nail down such
> behaviours? and perhaps any BGP communities that are well known to
> apply such so that these errors are less likely to happen, and less
> likely to receive the ire of some operators when germany -> australia
> -> germany paths tend not to exist?
Just setup IPv6 BGP the way you do IPv4 BGP: "Production-style", not
A proposal for the APNIC IX has been given a few times already:
- get quality transit (from NTT etc.)
- give that transit to your member ISPs (to those that want to accept it)
- give member ISPs connectivity to each other
- no full-table swaps between members, unless those that are announcing
a full table are willing to provide production-quality transit
Total number of prefixes smaller than registry allocations: 110584
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
More information about the ipv6-ops