paul at timmins.net
Sun Sep 26 22:20:20 CEST 2010
Gert Doering wrote:
>> They are obliged to work within the architecture that IETF lays out.
> If the IETF tries to mandate something that the RIR members don't accept,
> what then?
And as a RIR member who needs to see IPv6 adoption happen, I'll expend
all my available resources in that arena to ensure that a return to this
'only ISPs can have PI addressing' nonsense dies a quick death.
And I say that as an ISP. My customers need more reasons to migrate, not
>> The IETF doesn't pretend to be involved in economic issues, as you well know.
> Address allocation is massively influenced by economic factors. So trying
> to dictate allocation policy and at the same time claiming "economics are
> of no interest to us" is FAIL.
> (The IETF tried this before, with the "there must only be 8192 TLAs in
> the default-free zone" approach - and never came up with any guidance
> that enabled anyone to decide who is big enough to receive a TLA, and who
> has to adjust their business model to "no, you are too small, base your
> whole ISP operation on 3rd-party space". FAIL.).
Double fail, and as an ISP that has grown drastically in the last 3
years, I'm glad that died a quick death. I've already renumbered my
network once, back when it truly was small. Never again.
>> Again, we're not here to discuss policy. Our point is about
>> architecture. Policy decides who qualifies for what role. Architecture
>> is deciding how the technical pieces must be put together to scale.
>> >From an architecture point of view, both PI and PA are just "blocks of
>> addresses used to number devices and visible in the global routing table".
>> The difference is purely policy-wise: what strings are attached to this
>> specific block of addresses, what price tag is attached.
>> Now, I'm not saying that PI is the "right" or "only" way forward - but some of
>> the statements made above just don't reflect my pocket of reality
Too many times I hear IETF members saying 'we need more input from the
operations community, you all should join our mailing lists'.
This to me poses 2 obvious issues:
1) You recognize you are making decisions in a vacuum and do it anyway
2) The burden is on the people doing this stuff every day to make
sure some ivory tower policy doesn't pop out of nowhere and stomp on
whatever they were doing to get stuff done.
I propose the IETF do two things to help scalability:
1) Sit on their hands. Until they know what's happening out here,
any policy making is completely stupid.
2) Listen to what people are saying. I hear all sorts of terrible
arguments for why IPv6 should have NAT. I disagree this should happen. I
*do* agree the customers shouldn't have to renumber their entire
networks every time they switch IPs. There are currently two ways of
b) Large scale PI distribution, for free, so networks can get
As much as I favor the vendor lockin that forcing my customers to
use my space on their internal networks creates, I want them to see the
benefits, and I don't want them locked into SOMEONE ELSE'S PA space.
So if the IETF wants to do something, solve that dictomy and we'll be
much further along.
As for the routing table growth? Well, IPv6 has the above problem,
either we need NAT or PI addresses for everyone before the majority of
businesses will accept it.
So if we're going forward, let's either decide to create a standard way
to do NAT, and a way to detect it, and a way to request translations.
Individual sites can decide to restrict the ability to request
translations, sure, that's their right, but that will give me ammo as an
operator to explain who just broke protocol X (them, as they're not
fully implementing the RFC)
Or let's give everyone PI space and find a good protocol to aggregate it
As far as routing bloat without changes to this policy, that is a self
fixing problem. Currently we are announcing 4 IP blocks via BGP, and
will probably be announcing 6 before we start to not need them anymore,
or maybe even more.
Under IPv6 we will need one. That's a 6:1 aggregation ratio just by
switching to IPv6. Not bad! And quite representative of the internet as
The slow start policies the RIRs had to use kept them from giving us a
/18 to start with, so now we have two /21s, a /20, and a /22.
More information about the ipv6-ops