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