IPv6 PI allocation
Daniel Suchy
ds at nix.cz
Fri May 18 09:13:26 CEST 2007
>> RFC3178 exists in some kind of fantasy world. Quoting from it, "3.
>> Basic mechanism": "We assume that our site is connected to 2 ISPs, ISP-A
>> and ISP-B."
>>
>> This is an unrealistic requirement for the reasons I spelled out (the
>> need to connect to an IXP,
>
> no need to connect to any of IXes (by IXP you mean Internet eXchange
> Points - am I right?).
Why you imply no need here? PI is not only about connection to _two_
ISPs. IXP connection is RFC3178 suggests choice of some providers
_forever_ or for a very long time or implements need to renumber whole
network in case of ISP change (which can come on). And it's not easy to
renumber large network. Just think about reasons, why some networks
chose IPv4 PI address space.
>> plus the need for independence from any ISP's
>> network
> this is not fullfilled by RFC3178, that's true. see below.
>> - you cannot withdraw an announcement from a particular broken
>> upstream except by pulling all DNS records).
> you can workaround this with RFC3178. the assumption is that ISP-A
> and ISP-B are having transit relationship with each other, that's all.
Due to security reasons are many providers doing ingress filtering (it's
not a rare problem). RFC3178 assumes that there are NOT ingress filters
for multihomed networks at ISP side - but this is a security issue and
it's not acceptable these days.
There's another option - current IPv4 PI users just becomes a LIR and
obtain needed resources in this way - it's just question of money.
Blocking of PI allocations does not stop routing table grow.
Daniel
More information about the ipv6-ops
mailing list