[address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI)

Hi,


Am 09.07.2011 um 09:30 schrieb Turchanyi Geza:

> Nigel,
> 
> thanks for your words, espacially for your point 2.
> 
> However, your point 1 should be refined
> 
> 
> 
> 1. As far as I can see there are no fiscal issues here apart from the usual issue of more PI's meaning more NCC work meaning more staff (potentially) and hence more costs.
> 
> The potential cost of applying more staff at the RIRs like RIPE NCC is just one issue. The more important issue is that  all the line cards of the core routers should be replaced if we can not limit the grows of the forwarding tables (FIB)s. AND IPv4 address space trading allready might create problems concerning the grows. 
> 
> A total upgrade beed a couple of billon dollars. Unfortunately even if this many could be spent, the slow down provoked by the bigger table size could not be avoided. 
> 
> Therefore if we want to avoid total collaps or total up-grade and slow down in the very near future then all the FIBs grows should be minimised.
> 
> Any proposal that might provoke a sudden grows of the FIBs should be postponed until the technology would evolve enough and allow to handle fast enough tha definitely larger FIBs.
> 

you still haven't provided any reasons why there should be a sudden spike and evidence suggesting that there will be.
Why are you insisting on this? What is your secret agenda? Do you have any information you're not sharing?

Again, and i just also repeat myself now, because mindless repetition seems to be cool in this discussion:

- There already IS IPv6 PI in every RIR Region, i think you're barking up the wrong tree, we're not discussing the introduction of IPv6 PI here,
  you're some years late

- It's highly unlikely that there will be more IPv6 PI Prefixes than IPv4 PI Prefixes any time soon in ANY way, that's BY DESIGN of IPv6
  ("one prefix per entity" - usually). If your routers cannot handle that, you're doing something seriously wrong, or you have a wrong idea
  about the whole concept

- It's highly likely that the IPv4 table WILL grow faster if PI-shops aren't able to use IPv6 without multihoming because they
  will literally buy smaller and smaller IPv4 prefixes and announce them to stay in business when they grow, so instead of one IPv6 PI Prefix you will
  provoke 10 IPv4 PI Prefixes in some cases - because THERE ALREADY IS NO MULTIHOMING REQUIREMENT for IPv4 PI
  If you want to do something about that, provide a counter-proposal retroactively introducing a multi-homeing requirement on IPv4 PI please and
  see what will happen. If it goes through and is accepted, we have the same policy for IPv4 and IPv6 PI again, and i'm also happy :-)
  </sarcasm>

- It's almost completely independent of this proposal as long as HE does provide free IPv6 BGP Upstream tunnels :-)
  So why opposing this proposal at all if it does mean nothing for clueful people who just use a HE.net Tunnel as 2nd Peer and be happy to comply
  with the current policy? (okok, some might not want to do BGP themselves and pay for an AS# and so on, i admit this last one is rather
  a fun argument :-) But it makes a point that this proposal will have almost no impact if you look closer)

All this proposal does is ease up IPv6 deployment for some entities who - for whatever stupid reason - rely on PI addresses without being
multi-homed themselves.
And THAT is what the majority should want, more IPv6, soon.

Really, i still don't get it. Especially since the only problem here is the difference in IPv4 and IPv6 policies. It's more or less
a transition problem for now.
Why all the fuss NOW about such a simple policy change. This all was discussed years ago during the fight over IPv6 PI introduction.
Now, did the world end with IPv6 PI? No. 
Will the world end with IPv6 PI? Probably, but i will have bought new routers long before that happens anyways.
Is there more IPv6 deployment now? Yes (see number of PI assignments).
I really like the outcome.

-- 
Mit freundlichen Grüßen / Kind Regards

Sascha Lenz [SLZ-RIPE]
Senior System- & Network Architect