[6bone] Who respect RFC2772 ? (4. Routing Policies for the 6bone)

[Nicolas DEFFAYET]

6bone folks,

Flames & co > /dev/null


RFC2772: http://www.ietf.org/rfc/rfc2772.txt


4. Routing Policies for the 6bone

   Leaf sites or pNLAs MUST only advertise to an upstream provider the
   prefixes assigned by that provider. Advertising a prefix assigned by
   another provider to a provider is not acceptable, and breaks the
   aggregation model. A site MUST NOT advertise a prefix from another
   provider to a provider as a way around the multi-homing problem.
   However, in the interest of testing new solutions, one may break this
   policy, so long as ALL affected parties  are aware of this test, and
   all agree to support this testing.  These policy breaks MUST NOT
   affect the 6bone routing table globally.

   To clarify, if one has two upstream pNLA or pTLA providers, (A and B
   for this example), one MUST only announce the prefix delegated to one
   by provider A to provider A, and one MUST only announce the prefeix
   delegated by one from provider B upstream to provider B. There exists
   no circumstance where this should be violated, as it breaks the
   aggregation model, and could globally affect routing decisions if
   downstreams are able to leak other providers' more specific
   delegations up to a pTLA. As the IPNG working group works through the
   multi-homing problem, there may be a need to alter this rule
   slightly, to test new strategies for deployment. However, in the case
   of current specifications at the time of this writing, there is no
   reason to advertise more specifics, and pTLA's MUST adhere to the
   current aggregation model.

   Site border routers for pNLA or leaf sites MUST NOT advertise
   prefixes more specific (longer) than the prefix that was allocated by
   their upstream provider.

   All 6bone pTLAs MUST NOT advertise prefixes longer than a given pTLA
   delegation (currently /24 or /28) to other 6bone pTLAs unless special
   peering arrangements are implemented. When such special peering
   aggreements are in place between any two or more 6bone pTLAs, care
   MUST be taken not to leak the more specifics to other 6bone pTLAs not
   participating in the peering aggreement. 6bone pTLAs which have such
   agreements in place MUST NOT  advertise other 6bone pTLA more
   specifics to downstream 6bone pNLAs or leaf sites, as this will break
   the best-path routing decision.

   The peering agreements across the 6Bone may be by nature non-
   commercial, and therefore MAY allow transit traffic, if peering
   agreements of this nature are made. However, no pTLA is REQUIRED to
   give or receive transit service from another pTLA.

   Eventually, the Internet registries will assign prefixes under other
   than the 6Bone TLA (3FFE::/16). As of the time this document was
   written in 1999, the Internet registries were starting to assign /35
   sub-TLA (sTLA) blocks from the 2001::/16 TLA. Others will certainly
   be used in the future.

   The organizations receiving prefixes under these newer TLAs would be
   expected to want to establish peering and connectivity relationships
   with other IPv6 networks, both in the newer TLA space and in the
   6bone pTLA space. Peering between new TLA's and the current 6Bone
   pTLA's MAY occur, and details such as transit, and what routes are
   received by each, are outside of general peering rules as stated in
   this memo, and are left up to the members of those TLA's and pTLA's
   that are establishing said peerings. However, it is expected that
   most of the rules discussed here are equally applicable to new TLAs.


I do my demonstration with the ASpath-tree statistics of the routing
table of 5 pTLA:

Hurricane: http://ipv6.he.net/bgpview/odd-routes1.html
Verat: http://lab.verat.net/ASpath-tree/odd-routes1.html
Cybernet: http://sarah.muc.eurocyber.net/bgp/odd-routes1.html
Sprint: http://www.sprintv6.net/aspath/odd-routes1.html
Tilab: http://net-stats.ipv6.tilab.com/bgp/odd-routes1.html

AS14609
3ffe:a00:13::/48

AS15709
2001:650:10::/48
 
AS1741
3ffe:2620::/32

AS17934
3ffe:516::/32

AS2012
3ffe:2c03::/32

AS3327
3ffe:1200:3028:88a0::/64
2001:670:8B::/48

AS3561
2001:648:800::/48

AS3776
3ffe:2900:1109::/48

AS4181
3ffe:81d0:104::/48

AS8145
3ffe:26ff:10::/48

AS818
3ffe:b00:2000::/40
2001:410:400::/40

AS8812
3ffe:2650:1::/48

AS8209
2001:6E0:202::/48

AS8627
2001:608:1::/48

AS6680
2001:798:80:400::/62
2001:798:80:404::/62
2001:798:80:408::/62
2001:798:80:414::/62
2001:798:80:418::/64
2001:798:80:40C::/62
2001:798:20:200::2/128

ASNET
2001:288:3B0::/44

ATT-LABS-EUROPE
3ffe:1CFF:0:EE::/64

BELBONE-BE
3ffe:80b0:1001::/48

BELNET-BE
3ffe:80a0:1005::/48
3ffe:608:2::/48

BERKOM
3ffe:8090:4800:4E20::/64

BT-LABS
2001:7F8:2::/48

CHELLO
3ffe:82bf:2::/48

CHTTL-TW
3ffe:830f:2000::/40
3ffe:400c:3::/48
3ffe:8320:2:f::/64
3ffe:4008:e::/48
3ffe:4005:10::/48
3ffe:400b:6002::/48
3ffe:4010:a00b::/48
3ffe:4005:a::/48

COSY
3ffe:8034::/34

CUDI
2001:448:3::/48

DIVEO-BR
3ffe:2b00:1003::/48

DOLPHINS-CH
3ffe:8150:2001::/48

EAFIT
3ffe:8070:1015::/48

FUNET
3ffe:2620::/32

GENDORF
3ffe:400:3b0::/48

GLOBALCENTER
2001:7F8:1::/64

HURRICANE
3ffe:1200:3028::/48

ICLINVIA
3ffe:2610:10::/48

INTEC
2001:200:500::/40

ISC
2001:500::/48

JOIN
3ffe:2100:1:17::/64
3ffe:400:280::/48

NEXTGEN-LAB
3ffe:82bf::/32

NORDUNET
2001:6B0:4::/48

NTUA
2001:648:2::/48

RISQ
2001:410:300::/40

SAVVIS
3ffe:1300:4:2::/64
3ffe:1300:4:4::/64
3ffe:1300:4:1::/64
3ffe:1300:4::/48
3ffe:1300:4:3::/64
3ffe:1300:4:228::/64
3ffe:1300:4:1228::/64

SDSCNET
3ffe:2807::/32

SE-IP
3ffe:2640::/32

STBEN-BE
3ffe:80B0:100:8000::2/127
3ffe:80B0:100:8000::4/127
3ffe:80B0:100::/48
3ffe:80B0:100:1::/64

TVD
3ffe:80b0:1002::/48
3ffe:2501:100::/48

UDG
3ffe:8240:8012::/48

ULANC
2001:630:80::/48

UUNET-FR
2001:600:14::/48

UUNET-US
3ffe:8090:4800:4e20::/64
3ffe:8090:4800:ce50::/60
3ffe:1cff:0:ef::/64
3ffe:8090:4800:c005::/64
3ffe:8090:4800:c000::/64
3ffe:8090:4800:ce10::/60

VERAT
3ffe:400:10E0::/48
3ffe:8271:A090::/44
3ffe:80A0:1005::/48


The pTLA said in their pTLA request that they agree to all current and
future rules and policies !

Do you think that this pTLA who don't respect the RFC2772 must keep
their pTLA ?