I-D Action:draft-azinger-scalable-addressing-00.txt

[Mark Smith]

On Sun, 26 Sep 2010 16:20:20 -0400
Paul Timmins <paul at timmins.net> wrote:

> 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 
> less.
> >> 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.
> [snip]
> >> >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 
> doing this:
>        a) NAT
>        b) Large scale PI distribution, for free, so networks can get 
> stable addressing.

Your "currently" doesn't seem to include IPv6's preferred and valid
address lifetime methods, used to phase addressing in and out over
time, and ULAs to create stable internal addressing independent of
their current global addressing.

This is one problem that some operators need to work on -
they sprout off about how IPv6 should work and what the IETF has done
wrong with it, yet don't seem to know how it actually does work.

And just in case somebody accuses me of living in a fantasy land,
phasing address spaces in and out and ULAs aren't perfect, but
then neither is NAT and PI. It's about picking the compromises you're
willing to make. I've personally made enough with NAT, so I want to see
it die.


>     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.
> and
> 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 
> where possible.
> 
> 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 
> a whole.
> 
> 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.
> 
> -Paul