[arin-ppml] Stepping forward, opening my mouth and removing all doubt about
tedm at ipinc.net
Thu Aug 28 01:07:31 EDT 2008
> -----Original Message-----
> From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf
> Of William Herrin
> Sent: Wednesday, August 27, 2008 2:32 PM
> To: Ted Mittelstaedt
> Cc: ARIN PPML
> Subject: Re: [arin-ppml] Stepping forward, opening my mouth
> and removing all doubt about
> On Wed, Aug 27, 2008 at 3:55 PM, Ted Mittelstaedt
> <tedm at ipinc.net> wrote:
> > This is not correct - those big ISP's are big because they
> have a lot
> > of customers - those customers are the ones using the IP numbers.
> I have yet to connect to a residential Internet service (be
> it 56k modem, DSL or cable) that has assigned me an RFC1918
> address. The blackberry on my belt even appears to be using
> its own globally routeable IP address.
> How many hundreds of millions of addresses are consumed by
> similar uses?
> Is it your position that more than 10% of those users would
> be inconvenienced by having an RFC 1918 address behind a NAT
> box instead?
No, however the issue is that with those large ISP's almost
certainly a percentage of their customers are running some app
that is dependent on a public IP. The large ISPs do not want
to have to deal with the thousands of irate phone calls that
would result out of their million+ customer base if they
just arbitrairly switched people over to private IP numbers.
Now, this does not mean that they couldn't do a gradual
switchover, I agree. But I don't agree that it is for
us to force them to do it.
> I recently had the opportunity to do some passive traffic
> analysis on one of the California POPs for a major DSL
> provider. Just under a /14 of addresses was routed to this
> POP. That's around a quarter million addresses. The grand
> total number of unique addresses observed sending traffic
> this March? Less than 6000.
> That's the -reality- of address assignment at the mega-ISPs,
> and if it's even within an order of magnitude of typical then
> we have decades of addresses available for IPv4 just by
> recovering the waste.
Hey, I was running NAT even before Cisco had it in their code,
I was running the set of patches for divert sockets on the
FreeBSD 2.1 kernel back when most people thought a NAT was
a little bug that flew around annoying people - and I had
a 50 person/100+ host business behind it which I was admining
years before I ever worked for an ISP. And it worked
great. So your not going to find anyone who is more
familiar with the great things IPv4 NAT can do.
BUT - the fact of the matter is that stateful inspection
of packets through a firewall shouldn't require this icky
disgusting rewriting of source IP addresses. NAT is a
transition technology and it has a lot more years left in
it, but we cannot lose sight of the fact that it is a hack,
despite our amazement that the elephant can actually dance.
And you do not lay the foundations of a stable Internet
on a hack.
Yes, IPv6 conversion is not simple. Hell, our largest
upstream feed promised me last year they would have
native IPv6 running by now. I contacted them a few
months ago and I got a song and dance about how they
would have to charge us more money - turns out that rather
than do what they said they would do, they lined up some
IPv6 tunnel brokers with the intent to have their
customers pay extra money for tunnelling. Screw that.
Fortunately, all our contracts with them are coming due
We need to continue the slow slogging towards IPv6 -
everyone does, really. Consider that we are at a nexus
point in the growth of the Internet. One path leads down
the NAT trail and the other leads down the IPv6 trail.
It is just like the automotive industry, which is facing
a similar nexus. One path leads down squeezing even more
mpg out of our gasburners, and drilling anywhere we can
find a scrap of oil, and putting coal-to-oil schemes online
asap. The other path leads to hybrids, then plug-in-hybrids,
then finally electric passenger cars, with wind generation
by the utilities supplying the grid power.
If we keep doing what we are doing with IPv4 it will be
easier for a while - just as if we just keep squeezing the
gasoline infrastructure in passenger car vehicles it will
be easier for a while. If we go full-bore damn-the-torpedos
into IPv6 it will be much more difficult right away but
better in the long run. Just like converting the passenger
car fleet to electric will leave plenty of diesel for
the long haul trucks and give us enough time to get
freight infrastructure back on to rail.
But, you cannot make the IPv4 infrastructure last another 20
years, just as we can't make gasoline powered passenger cars
last another 20 years.
Bill, I don't know how old you are but I am too young to
be from the original generation that got the Internet going,
I'm not from the Jon Postel generation. But I am too old to
be from the YouTube generation. I have a foot both in the
old guard, as I can remember what the green-screen days were
like, I've actually seen a VAX boot up - yet I'm also helping
people today to run Flash and their digital cameras and all
of that. My generation knows both the Internet Generation That
Was, and the Internet Generation That Is To Come. It is my
generation's responsibility to take the same care of the Internet
that the Generation That Was took care of when they handed it
over to us, and took their millions and retired early. When
we got it, sure it was warty - SMTP with big holes that spammers
exploited, and legacy IP number holders who are ghosts in
the machine - but by and large it was OK.
Your asking my generation to committ a terribly immoral act
by making the very fabric of the Internet dependent on a cheap
hack. Are we to then hand a huge messy hairball over to
The Internet Generation That Is To Come for them to untangle?
It really saddens me that so many people see only the short
term IPv4 solutions of a few dozen years at most and run pell-mell
towards them. Although with the shoddy leadership of the
last 8 years in the US government setting a spectacular example
of short-term-solutions, I guess I shouldn't be too surprised.
More information about the ARIN-PPML