APNIC IPv6 transit exchange

Gert Doering 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 
"6bone style".

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

Gert Doering
        -- NetMaster
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 mailing list