IPv6 multihoming

[Brian E Carpenter]

On 2011-02-06 03:44, Bernhard Schmidt wrote:
> On 05.02.2011 14:52, Bernd Walter wrote:
> 
> Hi,
> 
>>>> If you mean that punching holes in PA blocks is a bad idea, I agree,
>>>> but really only for the same reason - it doesn't scale to millions,
>>>> only to thousands. Once people accept /48s, PI or PA are just about
>>>> the same.
>>>
>>> I don't agree. A lot of /48s in PA space look like unintentionally
>>> leaked more-specifics from iBGP, while a /48 from PI space is usually
>>> intentional.
>>>
>>> Which is why I'm (of course) accepting /48 from PI+IXP ranges but not
>>> only up to /36 from PA.

I understand the motivation for that but it isn't obviously right.
Like it or not, punching holes in PA blocks is not exactly illegal and
as far as I know there's no general operational consensus about it.

My point was that logically speaking there's no difference between
a punched hole and a PI block - the protocols are blind to this.

   Brian


>>
>> So multihoming a /48 PA or allow another ISP to announce it during
>> transition phase is already considered bad practice?
> 
> This is a very controversial topic. If you need to do it this way it is
> enough that the old ISP sees the more-specific.
> 
>> You differentiate PI from PA space by using RIR databases?
> 
> No, all RIRs make their assignments from dedicated blocks. Here is my
> filter:
> 
> !
> ! Documentation prefix
> ipv6 prefix-list ISP-fulltable-in seq 5 deny 2001:DB8::/32 le 128
> !
> ! ARIN Microallocations
> ipv6 prefix-list ISP-fulltable-in seq 100 permit 2001:500::/30 ge 40 le 48
> ipv6 prefix-list ISP-fulltable-in seq 105 permit 2001:504::/30 ge 48 le 48
> ! ARIN IPv6-PI
> ipv6 prefix-list ISP-fulltable-in seq 110 permit 2620::/23 ge 40 le 48
> !
> ! RIPE Microallocations
> ipv6 prefix-list ISP-fulltable-in seq 200 permit 2001:678::/29 ge 40 le 48
> ! RIPE IXP
> ipv6 prefix-list ISP-fulltable-in seq 205 permit 2001:7F8::/32 ge 48 le 48
> !
> ! APNIC IXP
> ipv6 prefix-list ISP-fulltable-in seq 250 permit 2001:7FA::/32 ge 48 le 48
> ! APNIC portable assignments (http://www.apnic.net/db/min-alloc.html)
> ipv6 prefix-list ISP-fulltable-in seq 255 permit 2001:C00::/23 ge 40 le 48
> !
> ! AfriNIC PI
> ipv6 prefix-list ISP-fulltable-in seq 270 permit 2001:43F8::/29 ge 40 le 48
> !
> ! LACNIC IXP and Critical Infrastructure
> (http://www.lacnic.net/en/registro/)
> ipv6 prefix-list ISP-fulltable-in seq 280 permit 2001:13c7:6000::/35 ge
> 40 le 48
> ! LACNIC PI
> ipv6 prefix-list ISP-fulltable-in seq 285 permit 2801::/24 ge 40 le 48
> !
> ! 6to4 Anycast Prefix
> ipv6 prefix-list ISP-fulltable-in seq 300 permit 2002::/16
> ipv6 prefix-list ISP-fulltable-in seq 305 deny 2002::/16 le 128
> !
> ipv6 prefix-list ISP-fulltable-in seq 990 permit 2000::/3 ge 12 le 36
> ipv6 prefix-list ISP-fulltable-in seq 1000 deny ::/0 le 128
> 
> But as I said, a very controversial topic. In my eyes we should make
> sure to avoid the roating table bloat today and maybe relax the rules
> later if necessary. Others say it should be as easy and similar to IPv4
> as possible to help migration.
> 
> I'm not against more-specifics from PA per se, but as long as there are
> networks that continue to leak dozens of more-specifics and don't do
> anything about it I don't see a way forward. If there is a way to limit
> it, great.
> 
> Bernhard
>