Subject: RE: Stupid NAT tricks and how to stop them.

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 27 Mar 2006 10:57:30 -0800

> From: Keith Moore [mailto:[email-masked]] 

> > Unfortunately some protocol purity zealots still have to 
> realize that 
> > Linksys, Netgear, Belkin and consorts don't sell NAT boxes because 
> > they think NAT is good, they sell NAT boxes because 
> consumers want to 
> > buy them.
> 
> maybe this is because "protocol purity zealots" take a long 
> term view and want to preserve the flexibility of the net 
> "market" to continue to grow and support new applications, 
> whereas the NAT vendors are just eating their seed corn.

Your long term view is irrelevant if you are unable to meet short term
challenges.

If you can't provide the functionality that the customers want your protocol
purity comes down to 'you have to do it our way, oh and by the way we have
no interest in listening to you'.
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Mon, 27 Mar 2006 14:16:57 -0500

> Your long term view is irrelevant if you are unable to meet short term

very true.   but at the same time, it's not enough to meet short term
challenges without providing a path to something that is sustainable in
the long term.

---

From: Austin Schutz <[email-masked]>
Date: Mon, 27 Mar 2006 13:51:35 -0800

> challenges without providing a path to something that is sustainable in

	This is reasonable, but there is no realistic path to ipv6 that the
known world can reasonably be expected to follow.

	NAT is a done deal. It's well supported at network edges. It solves
the addressing issue, which was what the market wanted. It voted for NAT with
dollars and time. It is the long term solution - not because it is better, but
because it is.

	Saying that it is a deficient mechanism may be true, but it
won't slow or change deployment. We can say that using workaround solutions
such as static natting ports, etc. are akin to putting lipstick on a chicken,
but the ipv6 vs. NAT battle is over in the marketplace. Even router vendors
aren't supporting ipv6 well (there was a talk which hit on this at NANOG 34:
http://www.nanog.org/mtg-0505/steinegger.html).

	There may be specific applications where ipv6 is deployed and working
well (or so I hear). But NAT is ubiquitous. It's sort of like discussing
Lisp vs. c/c++. Lisp may be better, but for most practical discussions it's
not worth pursuing - the market has chosen c/c++ for the _vast_ majority
of applications. Any discussions are either relegated to very specific
niches or are historical, like non-qwerty keyboards (for english speakers).

	So the real question is: Given NAT, what are the best solutions to
the long term challenges?

	Austin

---

From: Scott Leibrand <[email-masked]>
Date: Mon, 27 Mar 2006 17:10:13 -0500 (EST)

> known world can reasonably be expected to follow.

I think a good number of exclusively-IPv4-using* realists (like myself)
will disagree with you here. (* Exclusively-IPv4-using except at
conferences like IETF and NANOG where native IPv6 access is provided.)

> dollars and time. It is the long term solution - not because it is better, but

NAT (plus CIDR) was the short-term solution, and is realistic as a
medium-term solution.  In the long term, though, I don't think it will be
the only solution.

> the long term challenges?

You seem to assume that IPv4 w/ NAT and IPv6 are mutually exclusive.  I
disagree.  I have IPv4 and NAT at home, for example, but my hosts all can
support IPv4/IPv6 dual stack.  If my DSL provider starts doing IPv6
DHCP-PD, I will make sure I have a gateway box that can do both IPv4 w/
NAT and IPv6 w/ DHCP-PD, and run everything dual stack.  That way I can
start accessing my own hosts without stupid static NAT/PAT tricks, but
still access the IPv4 Internet directly.

And if someday I want to switch to a new ISP who prefers not to give out
IPv4 addresses at all, that'll be fine with me, as long as my ISP provides
me IPv4 translation services to reach that portion of the Internet that is
still IPv4-only at that point.

-Scott

---

From: Keith Moore <[email-masked]>
Date: Mon, 27 Mar 2006 17:11:18 -0500

> known world can reasonably be expected to follow.

That's because people keep thinking that there needs to be a path from 
IPv4 to IPv6 that makes sense for all applications.  No such path 
exists, because applications vary widely both in how they use the 
network and in how much existing infrastructure they have.  No single 
path makes sense for all of them.

> dollars and time. It is the long term solution - not because it is better, but

NAT is a dead end.  If the Internet does not develop a way to obsolete 
NAT, the Internet will die.  It will gradually be replaced by networks 
that are more-or-less IP based but which only run a small number of 
applications, poorly, and expensively.

> but the ipv6 vs. NAT battle is over in the marketplace.

the battle isn't over as long as vendors want to keep selling products. 
  the shortcomings of NATs are now widely acknowledged.  there is a 
market opportunity for a better solution.

> Lisp vs. c/c++. 

no it's not, because any program that can be written in LISP can be 
written in C/C++, or vice versa.  OTOH, it is not in general possible to 
write a program that works in a non-NATted network and move that program 
to a NATted network unless you build additional infrastructure "in the 
core" of the NATted network that supports tunneling through the NATs and 
layers a new addressing scheme on top of the overlay network.

now if what you're saying is that we need a standard NAT extension 
protocol that does that, I might agree.  though IMHO the easiest way to 
do that is to make the NAT boxes speak IPv6.

Keith

---

From: Dave Cridland <[email-masked]>
Date: Mon, 27 Mar 2006 23:23:32 +0100

> dollars and time. It is the long term solution - not because it is 
Actually, no, the market didn't want a solution to "the addressing 
issue", because there was no such issue in the market at the time. 
Nor did it vote *for* anything.

The market voted against the outrageous prices charged by ISPs for 
"networked" access accounts, and they started voting about ten years 
ago. I'm far from convinced this was a matter of market scarcity of 
IPv4 addresses, even if the problem was well known by then in 
technical circles, I'm far from convinced that the market pricing of 
those access accounts was based on anything but the few higher level 
ISPs of the time charging a fortune.

Now, people have said that none of the NAT vendors automatically 
believe NATs are a good thing, but I've not noticed any of them 
pointing out their known disadvantages, either. Facts of the matter 
are that given a shortcut which avoids cost, lots of people will in 
general buy it, and other people will cash in on it.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

---

From: Austin Schutz <[email-masked]>
Date: Mon, 27 Mar 2006 15:42:58 -0800

> path makes sense for all of them.

	That's probably true, but it doesn't help if you are trying to
justify a move to ipv6 beyond some very limited and specific scope. Unless
all of a given organization's business applications which use ipv4 seamlessly
work in ipv6, a v4 -> v6 upgrade won't happen without a strong business
case.

	For smaller organizations NAT _is_ relatively seamless beyond
doing a bit of trickery at the network edge, despite the shortcomings.

<good comments snipped for brevity>

> market opportunity for a better solution.

	I agree, but that opportunity may be to enhance NAT rather than
throw it away (you state something similar in your conclusion).

> layers a new addressing scheme on top of the overlay network.

	This is true, no question. It is definitely an added burden. But
it's a burden which must be dealt with because it's not going away
any time soon. The ubiquity of NATs is common knowledge to application
developers.

> do that is to make the NAT boxes speak IPv6.

	Yes, I am saying we need this or something similar. It seems like
the current solution I've seen implemented is something like static port
mapping with private ip space behind the NAT for most applications. There's
still the limited known ports issue (discussed earlier) among several others
which are as yet either unsolved or unimplemented on the global scale.

	There is probably still room for improvement here if it can be done
seamlessly or you can show a real business benefit to changing, such as ease of
multihoming or multiplexing of outside address space. Otherwise people will
just stick with what works adequately well.

	Water flows downhill. Programmers are lazy. :-)

	Austin

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Tue, 28 Mar 2006 06:11:35 +0200

> medium-term solution.  In the long term, though, I don't think it will be

It will be if ISPs continue to charge for extra IP addresses, as they
probably always will.

> still IPv4-only at that point.

If your ISP charges you extra for more than one IPv6 address, what
will you do?

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Tue, 28 Mar 2006 06:13:48 +0200

Keith Moore writes:

> NAT, the Internet will die.

I hardly think so, but in any case, the solution is pretty simple:
give out IP addresses for free, instead of charging an arm and a leg
for anything other than a single address.  As long as ISPs won't
provide multiple addresses, or won't provide them except at
unreasonably high prices, NAT will remain.

---

From: Keith Moore <[email-masked]>
Date: Mon, 27 Mar 2006 23:35:21 -0500

> work in ipv6, a v4 -> v6 upgrade won't happen without a strong business

don't think upgrade; think coexistence.

> throw it away (you state something similar in your conclusion).

As an engineer, the right thing to do is to transition away from NAT 
(along with IPv4), so that eventually it can be discarded.

I'm not a marketing person, but if I do my best to think like one, I 
suspect that the way to market this transition is not to say "this new 
box helps you get rid of NAT" but instead "this is a new, enhanced NAT" 
(or since they don't actually use the word NAT to talk about consumer 
gear, call it something like "IPv6-ready Enhanced Address Management")

> any time soon. The ubiquity of NATs is common knowledge to application

for some applications, it's simply impractical; for other apps, it's 
much more expensive (in terms of added infrastructure and support costs) 
to operate them in the presence of NAT.  in either case the market for 
those apps is greatly reduced, and the apps are more expensive as a result.

> which are as yet either unsolved or unimplemented on the global scale.

again, this doesn't really solve the problem - it only nibbles off a 
small corner of it.  NATs do harm in several different ways - they take 
away a uniform address space, they block traffic in arbitrary 
directions, they hamper appropriate specification of security policies, 
and these days they often destroy transparency.  You have to fix all of 
those problems and still preserve (improve!) the plug-and-play nature of 
the NAT.  what you end up with is something like a router that does both 
v4 and v6, autoconfiguring itself in both cases (including getting 
address blocks from upstream networks), with transparent v6, NAT on v4, 
a sort of generic IPv4 application socks-like proxy built into the NAT 
that lets v4-only apps allocate outside addresses/ports, accept 
connections on them, and also initiate connections from them.

on top of that you need a stateful firewall that lets admins configure 
which hosts/apps can do what outside of the local network independently 
of whether they're running v4 or v6, NAT or no NAT. ideally the firewall 
should be able to talk securely to an external policy server so that 
policy can be specified centrally for several routers in an enterprise 
network.

you need a standard network management interface to these boxes also, 
and probably a few ALGs built into the box for backward compatibility 
with protocols like IPv4 FTP.

then you can define protocols that lets hosts detect whether they're 
behind such an Router with Enhanced Address Management (REAM?) and APIs 
so that apps living on REAM-aware hosts can operate more transparently.

the reason this looks so complicated compared to NATs is that NATs never 
really worked all of this stuff out.  NATs started with a simple design, 
pretended it would work well without doing the analysis, and have been 
trying to fix it with bizarre hacks ever since that have only made the 
problem worse.

Keith

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Tue, 28 Mar 2006 07:00:10 +0200

> don't think upgrade; think coexistence.

How do IPv4 and IPv6 coexist?  Like ASCII and EBCDIC, perhaps?

> (along with IPv4), so that eventually it can be discarded.

I'm not aware of a smooth transition option; how does it work?

And NAT is economically driven. Unless ISPs stop charging for extra
addresses, it's hear to stay.

> those apps is greatly reduced, and the apps are more expensive as a result.

It might still be cheaper than converting them to IPv6.

> and these days they often destroy transparency.

Agreed, but they reduce the amount of money you must pay to your ISP
each month by a factor of ten or more.

> trying to fix it with bizarre hacks ever since that have only made the

People will go to great lengths sometimes to save money.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 28 Mar 2006 11:35:22 +0200

On 28 mar 2006, at 00.11, Keith Moore wrote:

> NAT is a dead end.  If the Internet does not develop a way to  
> obsolete NAT, the Internet will die.  It will gradually be replaced  
> by networks that are more-or-less IP based but which only run a  
> small number of applications, poorly, and expensively.

...or you will see an overlay network build on top of NAT+IPv4 that  
abstracts the shortcomings away - aka what the peer to peer networks  
are doing. End-to-end addressing...

- kurtis -

---

From: Austin Schutz <[email-masked]>
Date: Tue, 28 Mar 2006 02:33:27 -0800

> connections on them, and also initiate connections from them.

	This sounds workable. But I really question whether there is an
adequate userbase who cares enough about these problems enough to support the
development and deployment of the more complex system you suggest.

	The limitations of NAT you mention make little difference to most
of the NAT users I am familiar with. These are typically end users or
small organizations. They generally don't know what they are missing, and NAT
works adequately well for their purposes. I don't foresee them switching or
"enhancing" unless there is some killer application as yet unsurfaced which
demands it and won't work adequately well with a limited amount of bizarre
hacks and workarounds.

	The financial penalty from using non-natted ipv4 space is less of
an issue to larger organizations. When address space becomes a more scarce
resource globally will they care enough about the limitations above and beyond
what bizarre NAT hacks marginally solve to fund ipv6 implementation?  Maybe. I
haven't seen any evidence of it yet, but maybe some time in the future they
will.

	Austin

---

From: Dave Cridland <[email-masked]>
Date: Tue, 28 Mar 2006 11:50:04 +0100

On Tue Mar 28 11:33:27 2006, Austin Schutz wrote:
> works adequately well for their purposes.

Ah, but there's more. NAT is sold as a firewalling solution, not as a 
cheap hack to share a single-user DSL.

> an issue to larger organizations.

The first time I saw NAT outside of the hacker-at-home was in a 
reasonably sized ISP, about ten years ago. Since NAT is sold as a 
foolproof plug-and-play firewall - the lack of global addressability 
is promoted as an advantage - then larger organizations do use it.

Dave.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Mar 2006 12:53:15 +0200

> no interest in listening to you'.

which is why some of us wrote draft-ietf-v6ops-nap

    Brian

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 28 Mar 2006 06:35:21 -0500

On Mar 28, 2006, at 5:50 AM, Dave Cridland wrote:

> Ah, but there's more. NAT is sold as a firewalling solution, not as  
> a cheap hack to share a single-user DSL.
>

NAT may be sold as a firewalling solution, but that doesn't make it so.

Regards
Marshall

> foolproof plug-and-play firewall - the lack of global  
> addressability is promoted as an advantage - then larger  
> organizations do use it.
>
> Dave.
> --

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Mar 2006 06:46:30 -0500

> abstracts the shortcomings away - aka what the peer to peer networks are 
> doing. End-to-end addressing...

the overlay networks depend on having some hosts that aren't behind a 
NAT to serve as tunnel endpoints for hosts that do.  this will become 
less viable in the future as IPv4 address space gets more and more scarce.

also, for the most part, overlay networks do not perform as well as 
native networks (there are exceptions, as in bittorrent).  so they do 
not abstract (all of) the shortcomings away.

OTOH, one transition path away from NATs might be to extend NATs so that 
they support creation of overlay networks.  such devices could also aid 
v4/v6 coexistence.

Keith

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 28 Mar 2006 06:55:32 -0500

Hello;

On Mar 27, 2006, at 11:13 PM, Anthony G. Atkielski wrote:

>> obsolete

This is connected to IPv6 address assignment policies at your friendly
local RIR. I would urge that people who are interested in this issue in
the ARIN region join the PPML mailing list and even consider coming the
Montreal ARIN meeting next month. There are two proposals coming up,  
2005-1 and
2006-4, which would both relax the assignment of PI IPv6 space.

Regards
Marshall Eubanks

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 28 Mar 2006 15:29:39 +0200

On 28 mar 2006, at 13.46, Keith Moore wrote:

>>> obsolete NAT, the Internet will die.  It will gradually be  
>>> replaced by networks that are more-or-less IP based but which  
>>> only run a small number of applications, poorly, and expensively.
>> ...or you will see an overlay network build on top of NAT+IPv4  
>> that abstracts the shortcomings away - aka what the peer to peer  
>> networks are doing. End-to-end addressing...
>
> the overlay networks depend on having some hosts that aren't behind  
> a NAT to serve as tunnel endpoints for hosts that do.  this will  
> become less viable in the future as IPv4 address space gets more  
> and more scarce.
>
> native networks (there are exceptions, as in bittorrent).  so they  
> do not abstract (all of) the shortcomings away.

They don't, but they do give the users back some of the benefit's  
they lost from being behind the NAT. However, that is now  
transpartent to the user. "Uh, I can't buy this VoIP service for some  
technical reason, but this cool Skype stuff just works...".

The problem is that for the users to get away from the NAT swap, they  
will need to go down the operators "value-added-services-path".

> OTOH, one transition path away from NATs might be to extend NATs so  
> that they support creation of overlay networks.  such devices could  
> also aid v4/v6 coexistence.

I think you will see v4+NAT && overlaynetworks && IPv6-for end to  
services the providers want to sell (see IPTV and VoIP). Note, that  
this is end-to-end INSIDE the providers network. There is no  
incentive (yet) for providers to allow end-to-end on the Internet.

- kurtis -

---

From: Scott Leibrand <[email-masked]>
Date: Tue, 28 Mar 2006 11:48:02 -0500 (EST)

> It will be if ISPs continue to charge for extra IP addresses, as they

They can charge for IPv4 addresses because they're perceived to be scarce.
With IPv6 they may be able to charge for allowing me a /48 instead of a
/56 or /64, but IMO they won't be able to assign me a /128 by default and
charge me if I want a /64.

> If your ISP charges you extra for more than one IPv6 address, what

Then I will switch ISPs.

ARIN guidelines specifically require ISPs to give out larger blocks when
requested.  If any ISPs try to be hard-nosed about it and give out /128's
anyway, it will be pretty easy to pressure & shame them sufficiently that
they'll feel it in the marketplace.

-Scott

---

From: Scott Leibrand <[email-masked]>
Date: Tue, 28 Mar 2006 12:10:56 -0500 (EST)

> How do IPv4 and IPv6 coexist?  Like ASCII and EBCDIC, perhaps?

Um, have you heard of dual stack?  My Windows XP does it quite
transparently (after I enable IPv6 at the command line), and presumably
Vista will do IPv4/IPv6 dual stack transparently without any command-line
enabling.

> I'm not aware of a smooth transition option; how does it work?

OS's (and anything with a TCP/IP stack) starts looking for both IPv4 and
IPv6 connectivity at connect time (DHCP for v4, DHCPv6 or RA's for IPv6).
If an ISP has enabled IPv6 on their network, the IP stack gets an IPv4
address and one or more IPv6 addresses.  When it goes to talk to a host
with a v4 address, it uses v4.  To talk to a v6 host, it uses v6.  If a
network wants to stop giving out v4 addresses, they provide v4/v6
translation capabilities of some sort.

> addresses, it's hear to stay.

As I argued in another message, IMO ISPs will not be able to charge extra
for an IPv6 /64.  That gives you basically as many hosts as your
routing/switching gear can handle on a single subnet (as you won't be able
to put 2^64 hosts on a single broadcast domain).

> It might still be cheaper than converting them to IPv6.

As long as you already have v6-capable gear, enabling IPv6 shouldn't be
significantly more expensive than running v4.  IMO it doesn't make sense
to try to run v6 on gear that only supports v4, but since pretty much all
new gear supports v6 now, folks should be able to gradually turn on v6 as
appropriate in their networks.

> each month by a factor of ten or more.

Your ISP charges you 9 times as much for IPv4 addresses as they do for
bandwidth?  I'd recommend switching ISPs.  All the ones I've seen charge a
small premium for additional IP space, but it's never more than about a
50% premium.

> People will go to great lengths sometimes to save money.

Or to avoid hassle.  I have a single IP on my DSL, and run NAT, mainly
because it's not worth the hassle to get additional IPv4 space.  However,
as soon as my ISP starts offering IPv6 with DHCPv6 Prefix Delegation, I'll
upgrade my NAT box to something that supports DHCPv6-PD.  That might be a
linksys/d-link/netgear box, or it might be a PC running Linux.

-Scott

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Tue, 28 Mar 2006 20:54:49 +0200

> charge me if I want a /64.

They will charge you for every address beyond one.  Wait and see.

BTW, giving out /64s is one reason why the IPv6 address space will be
exhausted in barely more time than was required to exhaust the IPv4
address space.

> Then I will switch ISPs.

They will all be doing it.

> they'll feel it in the marketplace.

How?  I haven't been able to pressure or shame my ISP into setting
rDNS correctly for my IP address.  In fact, nobody at my ISP knows
what that means.

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Tue, 28 Mar 2006 21:00:23 +0200

> Vista will do IPv4/IPv6 dual stack transparently without any command-line

How does your ISP handle this?

How much extra does your ISP charge you for IPv6 support?

> for an IPv6 /64.

A /64 is a criminal waste of address space; they _should_ charge extra
for that.

> That gives you basically as many hosts as your

And even with a million hosts, you'll be wasting fully
99.9999999999945% of the /64.

Do you see why IPv6 address space will soon be exhausted?

> appropriate in their networks.

When did all applications become capable of handling IPv6?

> bandwidth?

My current ISP doesn't even give me the option.  I'd have to change to
a much more expensive ISP before having access to that kind of luxury.

> I'd recommend switching ISPs.

Make your check payable to my ISP.

> All the ones I've seen charge a

Fifty percent is a small premium?

---

From: Scott Leibrand <[email-masked]>
Date: Tue, 28 Mar 2006 14:11:24 -0500 (EST)

> They will charge you for every address beyond one.  Wait and see.

We definitely will have to see how it shapes up in the US.  In Japan,
where they actually have IPv6 deployed to end users, it looks like most
ISPs are giving out /64's to home users, and /48's to business users:

http://www.apnic.net/meetings/18/docs/sigs/policy/policy-pres-tomohiro-ipv6-endusers.pdf

> They will all be doing it.

I doubt it.  There are RFC's (3177) and RIR policies
(http://www.arin.net/policy/nrpm.html#six54) that *require* ISPs to
allocated a /64 or larger unless "it is absolutely known that one and only
one device is connecting."

> rDNS correctly for my IP address.  In fact, nobody at my ISP knows

What is "correct" rdns?  Is adsl-066-156-091-129.sip.asm.bellsouth.net
"correct"?

-Scott

---

From: Scott Leibrand <[email-masked]>
Date: Tue, 28 Mar 2006 14:23:38 -0500 (EST)

> How does your ISP handle this?

They could do so (when they implement IPv6) by running dual-stack routers.

> How much extra does your ISP charge you for IPv6 support?

My ISP doesn't yet provide IPv6 support.  But at some point they (or
another ISP) will.

> A /64 is a criminal waste of address space; they _should_ charge extra

I don't think you understand exponential math as it applies to IPv6.
IPv6 was specifically designed to make this possible.  With /48
assignments and an HD ratio of .94, projections indicate a ~500 year
lifetime to exhaust the IPv6 address space.

> 99.9999999999945% of the /64.

Yep.  And since there are about 18,446,744,073,709,600,000 /64's, such
wastage is not a problem.  IPv6 was *designed* to make sure that address
space conservation is *not* required.

> Do you see why IPv6 address space will soon be exhausted?

If you consider hundreds of years "soon", then sure.

> When did all applications become capable of handling IPv6?

They don't need to be.  For the life of any existing applications, IPv4
connectivity will still be available in some fashion.

> > All the ones I've seen charge a small premium for additional IP space,
> > but it's never more than about a 50% premium.
>

No, usually it's a lot less than 50%.  More typical is like $5/mo extra
for additional IP(s).

-Scott

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Tue, 28 Mar 2006 21:24:22 +0200

> ISPs are giving out /64's to home users, and /48's to business users:

Looks like IPv6 will be exhausted even sooner than I predicted.

> one device is connecting."

See above.

So if I understand correctly, 99.99999999999999999% of the IPv6
address space has already been thrown away.  Why bother going to IPv6
at all?

> What is "correct" rdns?  Is
> adsl-066-156-091-129.sip.asm.bellsouth.net
> "correct"?

The correct rDNS is the one that matches my domain.

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Tue, 28 Mar 2006 21:48:24 +0200

> They could do so (when they implement IPv6) by running dual-stack routers.

Ah, so they aren't doing it _now_.  They'll probably be doing it Real
Soon Now.

> My ISP doesn't yet provide IPv6 support.  But at some point they (or

I guess that's when you'll find out how much extra they'll charge.

> I don't think you understand exponential math as it applies to IPv6.

Yes, I do, but most engineers don't, which is why they are repeating
the same mistakes they made with IPv4 in their implementations of
IPv6.

> lifetime to exhaust the IPv6 address space.

Wait and see.

> space conservation is *not* required.

There isn't any way to do that with any address space of any size as
long as people refuse to understand the difference between exponential
and linear changes.

> If you consider hundreds of years "soon", then sure.

It's going to be far less than hundreds of years.

> connectivity will still be available in some fashion.

Things that have to be aware of the Internet can hardly ignore a
change in something as fundamental as the size of an IP address.

> No, usually it's a lot less than 50%.  More typical is like $5/mo extra

How much do the additional IPs cost the ISP?

---

From: Austin Schutz <[email-masked]>
Date: Tue, 28 Mar 2006 12:22:40 -0800

> How much do the additional IPs cost the ISP?

	This is dependent upon the location and size of the ISP. An
ISP /16 in total size might pay ARIN $4500 per year, for example.
	That works out to about $.0057 per address per month. At the $5
mark that's about an 87300% markup, not too shabby.

	Austin

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 29 Mar 2006 01:00:44 +0200

> known world can reasonably be expected to follow.

Well, if you look at the rate at which the IPv4 address space is  
being used up, something will have to give at some point. Last year  
168 million IPv4 addresses were given out by the RIRs. That's about  
4.5% of the 3706 million usable IPv4 addresses, with 60.2% gone as of  
2006-01-01 and 1465 million addresses still available. (Give/take a / 
8 because of inconsistent IANA/ARIN records.)

In the past 10 years, there have been several years where the growth  
of the growth was less than the year before:

1996	1997	1998	1999	2000	2001	2002	2003	2004	2005
2.7	1.2	1.6	1.2	2.1	2.4	1.9	2.4	3.4	4.5

(The numbers represent the number of addresses used up in that year  
as a percentage of the 3.7 billion total usable IPv4 addresses.)

Those years where the growth was smaller than the year before never  
happened twice or more in a row.

This basically means that unless things take a radical turn, the long- 
term trend is accelerating growth so that remaining 40% will be gone  
in less than 9 years. Probably something like 7, as Geoff Huston  
predicts.

When this happens, it will become extremely hard to find IPv4  
addresses for new stuff, so many people/devices will have to share a  
single address through NAT. Today, NAT mostly works because it's not  
too hard to find someone who isn't NATed to coordinate the  
communication. With IPv4 depleted that situation will change for any  
new deployments, so NAT headaches will increase rapidly. (Bittorrent  
with half the peers behind NAT is no problem. Bittorrent with all the  
peers behind NAT is suboptimal. Bittorrent with everyone including  
the tracker behind NAT makes you want to look up the meaning of  
"sneakernet".) At that point, it becomes a no-brainer to add IPv6 to  
bypass the IPv4 NAT and soon people who still have enough IPv4 space  
will want to use IPv6 too because that gives them easier access to  
people who don't have an IPv4 address.

At this point ISPs will want to provide IPv6 services too because  
without that, IPv4-starved ISPs have a very hard time competing with  
IPv4-rich ISPs. With IPv6 they're still not on an even footing but at  
least the distance isn't as great.

In other words: even though we have significant NAT today, people who  
need/want an unmolested IPv4 address today can have it without too  
much trouble. When IPv4 addresses are gone, this will stop being the  
case and IPv6 will start to look much more appealing.

It would also help if by that time all software would work over IPv6.

> but the ipv6 vs. NAT battle is over in the marketplace.

For now. Even with NAT we need a constant supply of fresh IPv4  
addresses, which we're not going to have forever.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Mar 2006 10:41:26 +1100

> exhausted in barely more time than was required to exhaust the IPv4

	Which was why IPv6 when to 128 bits rather than 64 bits.
	64 bits of address space would have been fine to give
	everyone all the addresses they would need.  128 bits gives
	them all the networks they will need.
 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Wed, 29 Mar 2006 11:55:18 +1200

> exhausted in barely more time than was required to exhaust the IPv4

This is FUD. Care to back up your assertions with real analysis?

You might want to review (among other things):

http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-ipv6-roundtable-report.pdf

Thomas

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 28 Mar 2006 16:17:56 -0800

> of the growth was less than the year before:

Part of the problem here is that the allocation bundles don't map well into
nice clean annual buckets. It is the overall trend that matters, not the
fact that any given year had a higher or lower growth rate.

> in less than 9 years. Probably something like 7, as Geoff Huston

While the exact date of exhaustion is impossible to predict, Geoff's 2012
target is presented to placate those in serious denial. The fundamental burn
rate has been compound growth since 2000, and there is no reason for it to
slow. In fact at the past NANOG meeting John asked if anyone saw reason for
ARIN to pursue modifying the policy, and there was dead silence as no
organization was willing to slow their business model for 'the global good'.

At the same time, arriving at a lifetime anywhere near 2012 for the
remaining pool takes dividing it by a constant rate of ~.75 /8's per month
(the recent snapshot of cumulative outbound from the RIRs). On the other
hand, applying the effective 5 yr+ historical compound consumption rate to
the remaining pool shows that IANA runs out in late 2008
(http://www.tndh.net/~tony/ietf/5-yr-projection.pdf) at which point the RIRs
collectively having 18 months on hand. Any given RIR may run out sooner or
later than mid-2010 depending on their pool size and burn rate. All of this
assumes no change in behavior, and the only predictable change at this point
is a land grab. 

> least the distance isn't as great.

While you are correct, this seems to understate the case. The compound
consumption rate of the last 5+ years has been during wide deployment of
nat. While many still disbelieve, there really are organizations that have
exceeded the capacity set aside in rfc1918 and for business reasons are
refusing to deal with multi-layered internal nat. They understand the real
cost of this broken technology, and will not go there.

> It would also help if by that time all software would work over IPv6.

Unfortunately this is a case of the application dev community needing a
serious wake up call. The unrealistically long lifetime projections for IPv4
don't help in this regard either. 

> addresses, which we're not going to have forever.

Don't worry! The hopelessly in denial, nat-solves-all believers will
magically create a new batch in a couple of years when the current supply
runs out... ;)

Tony

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Wed, 29 Mar 2006 05:51:20 +0200

> Which was why IPv6 when to 128 bits rather than 64 bits.

That won't help.  It will add perhaps 25% to the lifetime of the
address space, no more.

> them all the networks they will need.

No, it does not. It's only twice as much as 64 bits, and 64 bits is
only twice as much as 32. Addressing schemes consistently allocate
addresses in a terribly shortsighted way as bit spans, rather than
address ranges, so address ranges are consumed much more quickly than
they should be.

This seems to be one of the most consistent mistakes of computer
engineers ever since computers were invented.  After all these
decades, they still have no clue.

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Wed, 29 Mar 2006 06:15:00 +0200

> This is FUD. Care to back up your assertions with real analysis?

Sure.

The consistent mistake engineers make in allocating addresses is that
they estimate capacity in terms of sequential and consecutive
assignment of addresses--but they _assign_ addresses in terms of bit
spans within the address itself, which exhausts addresses in an
exponential way.  They do this in part because they attempt to encode
information directly into the address, instead of just using it as a
serial identifier.  An address of n bits contains 2^n available
addresses _only_ if they are assigned serially and consecutively;
dividing those bits into any arrangement of smaller fields reduces
capacity exponentially.

For example, if you have a 16-bit address field, at first it looks as
those it has 65,536 addresses. And it does ... if you assign addresses
as 0000000000000001, 0000000000000010, and so on. But if you allocate
addresses by dividing those 16 bits into fields, you dramatically
reduce the total address space available. If you reserve the first
eight bits for a "vendor," and the second eight bits for a "product,"
you've cut the address space by 99.6%, not by 50%. You will run out of
addresses in record time, and yet you'll never use more than a tiny
fraction of the theoretical capacity of the address space. All because
you wanted the short-term convenience of encoding information into the
address itself.

Engineers make this mistake over, and over, and over.  I don't know if
they are just too stupid to understand the above concepts, or if they
are so arrogant that they think they can somehow short-circuit
information theory and do the impossible.

I tend to vote for arrogance, since I think (and hope) that engineers
aren't really that stupid.  And further evidence for pure arrogance is
that engineers try to allocate address spaces now for a future that
they are unable to imagine.  They allocate /64 fields out of 128 bits
for purposes that they understand now, even though the real need for
addresses is likely to be completely different (and unforseeable) by
the time addresses actually start to run short.

I know I'm wasting my breath; if engineers were that easy to persuade,
they would not have made the same mistake over and over for nearly a
hundred years.  I'm sure others have tried to point out their errors
time and again, especially in recent years as more people have caught
on to the problem.  But they can't be told.  They are convinced that
it won't happen to them, even though it happened to everyone else.

A 128-bit address seems like "more than the universe will ever need,"
and it definitely is ... but only if addresses are assigned serially
from the address space, without any information encoded into the
address itself.  As soon as you reserve any portion of the field in
any way, there are multiple exponential reductions in capacity, which
can exhaust the address space entirely in a very short time.

The mistakes have already been made with IPv6.  Someone decided to
allocate bit spans out of the address, instantly invalidating the very
vast majority of all possible addresses in the address space, and
thereby reducing address capacity exponentially.  Nobody really knows
how addresses will be used 20 years from now, so why do people try to
guess and sacrifice the capacity of IPv6 in the process?  Don't
they ever learn?

Is there a safe and conservative way of allocating IPv6 address space?
Yes.  Set the first 96 bits to zero, and set the remaining 32 to the
current IPv4 addresses.  When that runs out, set the first 95 bits to
zero, set the 96th bit to one, and use the remaining 32 bits for
another IPv4 address space.  And so on.  A space of 128 bits will last
for eternity in this way, and most of the space will remain available
for any conceivable future addressing scheme, even those we cannot
dream of today.  In other words, don't allocate bit spans within the
address field, allocate address _ranges_ out of the full 128 bits.

But I know that won't happen. However, perhaps this message will
remain archived somewhere so that I can say "I told you so" when the
address space finally runs out (I'm pretty sure I'll still be
around--we all will).

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Mar 2006 15:16:26 +1100

> decades, they still have no clue.

	Well for home users one really only needs to be able to
	request /64's as needed.  There is no need for home users
	to have contiguious /64's.  It means the ISP has some extra
	routes in there IRP.  If they really need contiguious /64's
	then have them renumber to get the contigious block, even
	then the block size doesn't need to be a power of 2.
	A /62 and an adjacent /63 will work.

	Allocating is powers of 2 is a trade off.

	I suspect the same will apply to cell phones etc.

	Renumbering is also much easier, though not perfect.  Time
	spent on improving renumbering support will also aid more
	efficient utilisation.  We have the concept of deprecated
	addresses in IPv6 which is a powerful tool if used correctly.

	Mark

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 29 Mar 2006 12:23:21 +0200

> fact that any given year had a higher or lower growth rate.

That's why I prefer to look at the RIR->ISP figures rather than the  
IANA->RIR figures. I have a few scripts on my server to download the  
statistics from the RIR FTP sites and parse them. (Have a look at  
http://bgpexpert.com/addrspace.php if you want to peruse the numbers  
yourself.) This is what the RIRs gave out the past few years:

      78.24 M  2000
      89.07 M  2001
      68.97 M  2002
      87.82 M  2003
     128.58 M  2004
     168.53 M  2005
      35.14 M  2006

> slow.

Look above. 35 million this quarter so far means we're going to end  
up below last year's 168 million unless things _really_ start cooking  
the next quarters. If you drill down a bit more we're actually  
recovering from a fairly big slump late last year. In order to  
deplete IPv4 (including the RIR reserves which are at an all time  
high of nearly 400 million) in 2010 the yearly address use needs to  
grow by an average 30%:

       Addresses left year end     used that year

2006           1304                    175
2007           1077                    228
2008            781                    296
2009            396                    384
2010           -104                    500

While a 30% growth rate isn't unprecedented (2003: 27%, 2004: 46%,  
2005: 31%), I have a hard time imagining how this can continue year  
after year. At some point, all of this has to relate to something in  
the real world. In North America and Europe, IP penetration is such  
that doing more of the same can't be exponential because you reach  
100% within a few years. The rest of the world could have exponential  
growth for a longer time, but since the top 12 countries take up 75%  
of all yearly IPv4 address usage those remaining 25% can't fuel a 30%  
growth on their own at this point.

Now all of this doesn't mean there can't be any new developments that  
change address usage, but it does mean it will have to be something  
new, like every cell phone getting its own IP address. The figures  
over the past few years suggest that high growth happens in short  
burst after which there is a relapse. The average growth since 2000  
was 16% even though 2003 - 2005 were double or triple that. If we  
land at 150 million this year it will have been 13%. At 16% we'll be  
out of IPv4 addresses in 2011, at 13% in 2012. So the difference  
between 30% and 13% is only two years...

> In fact at the past NANOG meeting John asked if anyone saw reason for

The question is: would modifying the policies to be more restricting  
be "the global good"? John Klensin says that we're out of IPv4  
addresses for all intents and purposes anyway because the addresses  
are too hard to get as it is. If it gets harder at the one hand this  
means life gets more difficult, but at the other hand it means we get  
to limp along for longer, making the period where IPv4 is painful but  
not painful enough to adopt IPv6 even longer.

However, it might make sense for the RIRs to stop giving out such  
ridiculously large blocks:

mysql> select rir, country, day, descr, num from addrspace where type  
= 'ipv4' and day >= '2000-01-01' order by num desc, day desc limit 8;
+---------+---------+------------+------------+----------+
| rir     | country | day        | descr      | num      |
+---------+---------+------------+------------+----------+
| apnic   | JP      | 2005-02-08 | 126.0.0.0  | 16777216 |
| arin    | US      | 2005-04-19 | 73.0.0.0   | 12582912 |
| ripencc | FR      | 2006-03-02 | 90.0.0.0   |  8388608 |
| ripencc | FR      | 2005-03-02 | 86.192.0.0 |  4194304 |
| ripencc | GB      | 2005-02-07 | 86.128.0.0 |  4194304 |
| apnic   | CN      | 2004-12-23 | 59.192.0.0 |  4194304 |
| apnic   | JP      | 2004-05-20 | 60.64.0.0  |  4194304 |
| ripencc | DE      | 2004-03-10 | 84.128.0.0 |  4194304 |
+---------+---------+------------+------------+----------+

If Softbank in Japan really needs 16 million addresses then it  
doesn't matter whether they get 1 /8 or 16 /12s, but if it turns out  
they really need 9 million then having them come back for /12s means  
they'll only end up using 9 of those and not wasting much address  
space, while with a /8 they'd be wasting 7 million addresses. At  
these levels routing table issues don't come into play.

[when we're out of IPv4 addresses]

>> At that point, it becomes a no-brainer to add IPv6 to

> cost of this broken technology, and will not go there.

Sounds like a good use for class E...

Actually I think the significance of NAT as an IPv4 address  
conservation tool is overstated. Yes, if you'd start giving every box  
with an RFC 1918 address a real address you'd be out of IPv4  
addresses before the day is over, but that was never a realistic  
scenario anyway. And before NAT we had proxies which allow the same  
thing for applications that support them.

> don't help in this regard either.

But unrealistically short projections won't help either. The truth  
is, that we simply don't know what's going to happen with any degree  
of certainty. Given that fact, I'd rather start with projections on  
the long side and adjust them down gradually. That way, people will  
see that this is serious within a few years. By giving out very short  
projections that have to be revised upwards people may assume this is  
going to continue indefinitely so they really don't have to do  
anything. And if it's really 2009 we'll be in trouble regardless of  
what we say now because there isn't enough time to get people into  
action fast enough to make for a smooth transition.

---

From: Scott Leibrand <[email-masked]>
Date: Wed, 29 Mar 2006 08:21:27 -0500 (EST)

Well, in the case of IPv6 we're currently playing in a sandbox 1/8 the
size of the available address space.  So if what you say is true, and we
manage to use up an exponential resource in linear time, then we can
change our approach and try again with the second 1/8 of the space,
without having to go through the upgrade pain that is the v4-v6
transition again.

I suspect even arrogant engineers can get it right in 8 tries.  :)

-Scott

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Wed, 29 Mar 2006 20:45:01 +0200

Scott Leibrand writes:

> size of the available address space.

So the lifetime of IPv6 will be 8 times its current age, since the
remaining 7/8 will probably be blown just as quickly.

> So if what you say is true, and we manage to use up an exponential
> resource in linear time, then we can change our approach and try
> again with the second 1/8 of the space, without having to go through
> the upgrade pain that is the v4-v6 transition again.

It will just be a different variation on the same mistake.

> I suspect even arrogant engineers can get it right in 8 tries.

They haven't gotten it right in the past century, so I'm not
optimistic about the future.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 29 Mar 2006 23:04:15 +0200

> optimistic about the future.

So how big would you like addresses to be, then?

We currently have 1/8th of the IPv6 address space set aside for  
global unicast purposes with the idea that ISPs give their customers / 
48 blocks. That gives us 45 bits worth of address space to use up.  
It's generally accepted that an HD ratio of 80% should be reachable  
without trouble, which means we get to waste 20% of those bits in  
aggregation hierarchies. This gives us 36 bits = 68 billion /48s.  
That's several per person inhabiting the earth, and each of those / 
48s provides 65536 subnets that have room to address every MAC  
address ever assigned without breaking a sweat.

What was the problem again?

---

From: Tim Chown <[email-masked]>
Date: Wed, 29 Mar 2006 22:12:57 +0100

> What was the problem again?

Apparently that Steve Deering is an arrogant, stupid engineer.

Allegedly ;)

-- 
Tim/::1

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Thu, 30 Mar 2006 06:26:48 +0200

> So how big would you like addresses to be, then?

It's not how big they are, it's how they are allocated.  And they are
allocated very poorly, even recklessly, which is why they run out so
quickly.  It's true that engineers always underestimate required
capacity, but 128-bit addresses would be enough for anything ... IF
they were fully allocated.  But I know they won't be, and so the
address space will be exhausted soon enough.

> global unicast purposes ...

Do you know how many addresses that is? One eighth of 128 bits is a
125-bit address space, or

42,535,295,865,117,307,932,921,825,928,971,026,432

addresses. That's enough to assign 735 IP addresses to every cubic
centimetre in the currently observable universe (yes, I calculated
it). Am I the only person who sees the absurdity of wasting addresses
this way?

It doesn't matter how many bits you put in an address, if you assign
them this carelessly.

> ... with the idea that ISPs give their customers /48 blocks.

Thank you for illustrating the classic engineer's mistake.  Stop
thinking in terms of _bits_, and think in terms of the _actual number
of addresses_ available.  Of better still, start thinking in terms of
the _number of addresses you throw away_ each time you set aside
entire bit spans in the address for any predetermined purpose.

Remember, trying to encode information in the address (which is what
you are doing when you reserve bit spans) results in exponential (read
incomprehensibly huge) reductions in the number of available
addresses.  It's trivially easy to exhaust the entire address space
this way.

If you want exponential capacity from an address space, you have to
assign the addresses consecutively and serially out of that address
space.  You cannot encode information in the address.  You cannot
divided the address in a linear way based on the bits it contains and
still claim to have the benefits of the exponential number of
addresses for which it supposedly provides.

Why is this so difficult for people to understand?

> That gives us 45 bits worth of address space to use up.

You're doing it again.  It's not 45 bits; it's a factor of
35,184,372,088,832.

But rest assured, they'll be gone in the blink of an eye if the
address space continues to be mismanaged in this way.

> aggregation hierarchies.

No. It's not 20% of the bits, it's 99.9756% of your address space that
you are wasting.

Do engineers really study math?

> This gives us 36 bits = 68 billion /48s. That's several per person
> inhabiting the earth, and each of those / 48s provides 65536 subnets
> that have room to address every MAC address ever assigned without
> breaking a sweat.

What happens when MAC addresses go away?  How are you providing for
the future when you allocate address space based on the past?  Why not
just leave the address space alone, and allocate only the minimum
slice required to handle current requirements?

That's another problem of engineers: they think they can predict the
future, and they are almost always wrong.

> What was the problem again?

And that's the third problem.

Remember also: any encoding of information into the address field
(including anything that facilitates routing) exponentially reduces
the total number of available addresses.  So it might look like 2^128
addresses, but in reality it may be 2^40, or some other very small
number, depending on how much information you try to encode into the
address.

---

From: Andrew McGregor <[email-masked]>
Date: Thu, 30 Mar 2006 19:30:25 +1200

> small premium for additional IP space, but it's never more than  

Not if you don't live in the US.  There are no options here that are  
at all cheap.  Usually you get a flat "we don't do that".  And they  
don't do v6 either.

And people wonder why NATs proliferate... much of the world has no  
option but to live with them.  This is a direct result of policy  
discouraging IPv4 address allocation.

Andrew

---

From: Eliot Lear <[email-masked]>
Date: Thu, 30 Mar 2006 09:47:27 +0200

Why would a service provider give up skimming the cream with that
(nearly free) extra cash that weirdos like us hand them for real IPv4
addresses?

Eliot

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 30 Mar 2006 11:29:04 +0300

Hi Andrew,

> discouraging IPv4 address allocation.

sorry for asking, but what policy are you referring to?

RIR policy?

Can you point out any RIRs policy that prevents from getting one public 
IPv4 address per machine connected to the Internet?

What do you think that needs to be changed in the v4 allocation policy?

Or are you talking about business model of the ISPs? (which doesn't 
seem to me to be related with policies, but just business...)

Thanks, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 30 Mar 2006 11:05:54 +0200

> Can you point out any RIRs policy that prevents from getting one  
> public IPv4 address per machine connected to the Internet?

On a somewhat (un)related note: it's not easy for ISPs to give out  
two or three IP addresses to customers because there is no good  
mechanism to do so. One address works very well with PPP or DHCP, but  
a specific number other than one doesn't, so the next step is  
something like a /29.

On an even more (un)related note: it's not possible to give IPv6  
addresses to customers over PPP, and it's very inconvenient to make  
a /64 - /48 be routed towards a customer router that dynamically  
connects to an ISP network. (I.e., my cell phone is a router and it  
dials up, it gets an address through stateless autoconfig but then my  
laptop, PDA etc that use the cell phone as their router aren't  
automatically reachable.)

Some more work on provisioning mechanisms wouldn't be a bad thing.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 30 Mar 2006 12:25:46 +0200

Dear Illjitsch,
full agreement with everything you say.

In addition please consider that engineers want to square several 
informations within a single space. So to the lose of numbering space 
they add rigidity wich operationnally kills still more space. 
Actually there is a 32 Hexa long address space. Question 1 is how 
many Hexa to protocol, how many to routing, how many to addressing 
and how many to subaddressing. Question 2 are the solutions to save 
space depending on the use within that ABNF without removing 
operational simplicity. It seems absurd to give my mobile as many 
local addresses than to a large corporation network. Question 3 is 
interoperability of the various addressing spaces.

Anyone having to build a numbering plan for any kind of nomenclature 
has the same problem and faces the same erroneous propositions. I 
wander if someone wrote a book about that kind of experience the 
world could take advantage from. The problem is that this 
incertainity blocks network application needind a stable relative 
numbering plans.
jfc

> > So how big would you like addresses to be, then?

<snip>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 30 Mar 2006 13:36:18 +0200

> it). Am I the only person who sees the absurdity of wasting addresses

When I first learned about IPv6 I felt strongly that 128 bits was too  
much, especially since all those bits have to be carried in every IP  
packet twice, once as a source address and once as a destination  
address. However, since that time I've learned to appreciate  
stateless autoconfiguration and the potential usefulness of having  
the lower 64 bits of the IPv6 address as a place to carry some  
limited security information (see SEND and shim6 HBA).

> entire bit spans in the address for any predetermined purpose.

The trouble is that you need to build in space for growth.  
Unfortunately, at the time IPv6 was created variable length addresses  
weren't considered viable. (In theory CLNP has variable length  
addresses, in practice that doesn't really work out.) And for some  
strange reason, apparently only powers of two were considered as  
address lengths. So the choice was either 64 bits, which is a lot,  
but it doesn't allow for any innovation over the 32 bits we have in  
IPv4, or 128 which does cost 16 extra bytes in every packet, but  
gives us stateless autoconfig and SEND. Now you can argue that 64 or  
48 bits and continuing current IPv4 practices would have been better,  
but given the choice for 128 bits, the current way of using the  
address space makes sense for the most part.

The only thing I'm not too happy about is the current one address /  
one subnet / /48 trichotomy. Ignoring the single address for a  
moment, the choice between one subnet and 65536 isn't a great one, as  
many things require a number of subnets that's greater than one, but  
not by much. For instance, the cell phone as a router example I  
talked about earlier. A /64 and a single address, or two /64s which  
would be a /63 would be more useful there. The idea that we'd use up  
too much address space by giving out /48s doesn't seem like a real  
problem to me, but on the other hand most people don't need a /48 so  
some choice thats < /48 and > 64 makes sense. But a /56 as suggested  
by some people is suboptimal: people with growing networks will at  
some point need more than 256 subnets but at that point they already  
have very many subnets so renumbering then is painful. Making the  
choice between /60 and /48 makes much more sense: just give everyone  
a /60 rather than a /64 just in case they need a handful of subnets,  
which is adequate for 99% of all internet users. People who need more  
than a handful of subnets can get a /48 and won't have to renumber at  
an inconvenient point in the growth curve.

Yes, I know this will use up sixteen times the number of addresses  
for people who really only need a single subnet, but it saves a  
factor 4096 for the people who need 2 - 16 subnets and would have  
gotten a /48 or a factor 16 for the people who would have gotten a / 
56. The extra wasted address space from giving people who really only  
need one subnet a /60 is made up for by the people who would have  
gotten a /48 but can now get by with a /60 if the ratio of one-subnet  
to <17-subnet users is 1 : 4000 or less. (Making the choice /64 vs / 
56 saves even more as long as the ratio is lower than 94 : 6 but  
doesn't have the desireable near-onesizefitsall quality.)

> addresses for which it supposedly provides.

The thing that is good about IPv6 is that once you get yourself a / 
64, you can subdivide it yourself and still have four billion times  
the IPv4 address space. (But you'd be giving up the autoconfiguration  
advantages.)

Also, when the time comes to create the next version of IP, we won't  
have to worry about all of this to a noticeable degree because IPvA  
or IPvF or whatever can have a different addressing structure that  
can still be expressed as an IPv6-like 128 bit number for backward  
compatibility with IPv6, which isn't possible today because IPv6's  
128 bits can't be expressed as an IPv4-like 32 bit number.

> No. It's not 20% of the bits, it's 99.9756% of your address space that

I'm not a huge fan of the HD ratio either, because it substitues a  
rule of thumb for actual knowledge. But the point is that EVEN if you  
waste 99.9756% in this way we STILL have enough addresses to give  
every person living on the planet when the population hits its peak  
several /48s which are wasteful in their own right.

So while I wouldn't want to take away your right to begrudge the way  
all of this is done in IPv6, I must object to your conclusion that  
we'll run out of IPv6 soon, for any reasonable value of "soon".

> Do engineers really study math?

Just the simple stuff.

> future, and they are almost always wrong.

I hope good engineers don't think that, but it's certainly true that  
as a rule, the future doesn't match what was predicted earlier.  
Engineers should build stuff that still works reasonably well even if  
they get their predictions wrong.

Unfortunately the people who want non-aggregatable provider  
independent addressing can't seem to understand that.

---

From: Tim Chown <[email-masked]>
Date: Thu, 30 Mar 2006 13:05:35 +0100

> the IPv4 address space. (But you'd be giving up the autoconfiguration  

I noticed that by deafult MS Vista doesn't use autoconf as per 2462, 
rather it uses a 3041-like random address.  See:
http://www.microsoft.com/technet/itsolutions/network/evaluate/new_network.mspx

"Random Interface IDs for IPv6 Addresses

 To prevent address scans of IPv6 addresses based on the known company IDs of network adapter manufacturers, Windows Server "Longhorn" and Windows Vista by default generate random interface IDs for non-temporary autoconfigured IPv6 addresses, including public and link-local addresses."

That reads to me like no 2462 by default.  Maybe I'm misinterpreting.

One could envisage an option where that randomness is applied to 48 host
bits not 64.  If you really really wanted to do that.

-- 
Tim/::1

---

From: "Steve Silverman" <[email-masked]>
Date: Thu, 30 Mar 2006 08:23:52 -0500

Anthony,

The problem with allocating numbers sequentially is the impact on
routers and routing protocols.
I have heard that the Japanese issue house numbers chronologically.
When you find the right block, you have to hunt
for the right number.  What you are suggesting is similar. You would
have as many routing table entries as hosts in the world.  The router
would not be affordable.  The traffic for routing entries would swamp
the net. The processing of these
routing advertisements would be impossible.  It doesn't scale!
The function of an address is to enable a router to find it. That is
why
we try to use hierarchical addressing even at the cost of numbering
space.

IMO one problem of the Internet is that it isn't hierarchical enough.
Consider the phone system:  country codes, area codes ...  This makes
the job of building a switch much easier. I think we should have
divided the world into 250 countries. Each country into 250
"provinces".  Yes, it would waste address space but it would make
routing much easier and more deterministic.  It would simplify BGP
drastically.  Current routing algorithms aren't that efffective.
Paths in the net are fairly inefficient. This increases latency,
apparent traffic on the net, and is a real waste of money.

Yes this would mean a mobile node needs to get new addresses as it
moves. So what. We already have DHCP.  Cell phones do a handoff
already.

Steve Silverman

> -----Original Message-----
> From: Anthony G. Atkielski [mailto:[email-masked]]
> Sent: Wednesday, March 29, 2006 11:27 PM
> To: [email-masked]
> Subject: Re: 128 bits should be enough for everyone,was:
> IPv6 vs. Stupid
> NAT tricks: false dichotomy? (Was: Re: StupidNAT tricks and
> how to stop
> them.)
>
>

---

From: John C Klensin <[email-masked]>
Date: Thu, 30 Mar 2006 10:44:43 -0500

--On Thursday, March 30, 2006 19:30 +1200 Andrew McGregor 
<[email-masked]> wrote:

>> Your ISP charges you 9 times as much for IPv4 addresses as
>> they do for bandwidth?  I'd recommend switching ISPs.  All
>> the ones I've seen   charge a
>> small premium for additional IP space, but it's never more
>> than   about a 50% premium.
>
> Not if you don't live in the US.  There are no options here
> that are  at all cheap.  Usually you get a flat "we don't do
> that".  And they  don't do v6 either.

If it makes you feel better (it probably won't), in much of the 
US, the story from the ISPs goes like this:

	* We don't do that on our residential service, if you
	want _any_ IPv4 addresses assigned to you, you need to
	buy the commercial service.
	
	* The commercial service costs around ten times as much
	as the residential one for similar bandwidth _less_
	service (often no free email, free web hosting, "user
	protection" software tools, etc.)

	* If you want more than one address on the commercial
	service, you will pay some small incremental charge for
	it.  But the real incremental charge starts at address
	number 1 and is tied up with the "type of service" shift.

However, we need to keep something else in mind, which 
Iljitsch's note hints at.  If I'm an ISP trying to sell a 
low-end service to low-end customers at a low  (but still 
profitable) price, I need to cut customer support costs to the 
absolute minimum.  If someone calls up for help with a 
configuration problem, that may be six month's of profits from 
that customer eaten up in the cost of answering the call.   To 
that sort of ISP, NATs, and ISP-supplied routers that support 
NATs, have a _huge_ advantage, which is that all supported 
customer LANs are identical -- same design, same exact internal 
addresses, etc.    That is very important from a support 
standpoint -- length of calls, skill levels required, ability to 
construct clear FAQs and avoid calls entirely, and so on.

For the community, there are elements of "you get what you pay 
for" in this.  And, for the ISPs, unless we figure out ways to 
provide the same level of support convenience with public 
addresses, we will certainly see NATs with IPv6 as well as IPv4.

     john

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Mar 2006 11:44:37 -0500

> However, we need to keep something else in mind, which Iljitsch's note 
> hints at.  If I'm an ISP trying to sell a low-end service to low-end 
> customers at a low  (but still profitable) price, I need to cut customer 
> support costs to the absolute minimum.  If someone calls up for help 
> with a configuration problem, that may be six month's of profits from 
> that customer eaten up in the cost of answering the call. 

I find myself wondering, don't they get support calls from customers 
having to deal with the problems caused by the NATs?

> For the community, there are elements of "you get what you pay for" in 
> this.  And, for the ISPs, unless we figure out ways to provide the same 
> level of support convenience with public addresses, we will certainly 
> see NATs with IPv6 as well as IPv4.

either that, or IPv6 will be seen as something that is "business use only".

Keith

---

From: Peter Sherbin <[email-masked]>
Date: Thu, 30 Mar 2006 08:47:23 -0800 (PST)

> If someone calls up for help with a 
> configuration problem, that may be six month's of
> profits from that customer eaten up in the cost of
answering the call.

That is because the current Internet pricing has been
screwed-up from the start. LD settlements between
telcos are fully applicable to ISPs but have never
been instituted. Internet has been subsidised for
years by the local access but now as wireline declines
everybody starts feeling the pain. Usage based billing
and inter-ISP settlements start showing up lately and
they fit well for the Internet. Otherwise transit
providers as well as heavy users rip all the benefits.

Peter Sherbin

> addresses, we will certainly see NATs with IPv6 as

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Thu, 30 Mar 2006 18:51:43 +0200

> at all cheap.  Usually you get a flat "we don't do that".  And they

True.

> discouraging IPv4 address allocation.

And a rather skewed allocation of address space, more evidence of
engineers not knowing what they are doing.

---

From: Theodore Ts'o <[email-masked]>
Date: Thu, 30 Mar 2006 12:03:04 -0500

> having to deal with the problems caused by the NATs?

No, because most customers browse the web, read e-mail, use skype/VOIP
services, and all of those work under NAT.  A number of VPN packages
break, (a) that's not that common compared the huge number of
residential customers that aren't doing VPN's for work-at-home setups,
andin any case, those complaints usually gets sent to the company help
desk, and a number of VPN's have solutions that work with NAT's
anyway.

The problems caused by NAT's are the sort of things that don't
normally show up at ISP help desks; the new applications that are not
written, the architectures that are torqued to deal with NAT's, etc.

					- Ted

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Thu, 30 Mar 2006 19:04:48 +0200

> packet twice, once as a source address and once as a destination  

When I first learned about IPv6 I started worrying that it wouldn't
last for very long before being exhausted in turn.  And I worried a
lot more when I saw the mistakes of the past being repeated--the very
mistakes that wasted so many IPv4 addresses.

> However, since that time I've learned to appreciate

Once it's carrying information, it's no longer just an address, so
counting it as pure address space is dangerous.

> The trouble is that you need to build in space for growth.

You build in space for growth by not trying to allocate address spaces
in advance.  For example, you allocate 0...0+33 bits for new
addresses, and now you've doubled the IPv4 address space (and bought
yourself years of additional time), while using up only an
infinitesimal portion of the IPv6 space.

But when you start chopping the address into sections, you throw
almost all the address space away ... and when that happens, you are
going to exhaust that space in no time, no matter how many bits it
has.

Building in space means not allocating it--not even _planning_ to
allocate it.  Nobody has any idea what the Internet might be like a
hundred years from now, so why are so many people hellbent on
"planning" for something they can't even imagine?

> weren't considered viable.

Variable-length addresses are the only permanent solution, unless IP
addresses are assigned serially (meaning that all routing information
has to be removed).

Variable-length addresses work very well for the telephone system, and
they'd work just as well for the Internet, if only someone had taken
the time to work it out.

> not by much.

It's a good example of waste that results from short-sightedness.  It
happened in IPv4, too.

> the IPv4 address space.

It sounds like NAT.

> several /48s which are wasteful in their own right.

Famous last words.  I've seen virtual memory systems run out of
virtual address space, even when that space contained (in theory) more
bytes than anyone could ever possibly build into any real-world
system.  The reason?  Careless allocation of the addresses.  No matter
how many bits you have, you can blow through them in linear time if
you allocate them based on bit fields, and it seems that virtually no
engineers can resist the urge to do exactly that.

> we'll run out of IPv6 soon, for any reasonable value of "soon".

Well, time will tell, won't it?

> I hope good engineers don't think that ...

Any engineer setting aside bit spans in an address for future use is
thinking exactly that, and he'll be wrong.

> they get their predictions wrong.

Engineers don't like to think that they've left anything out or that
they are less than omniscient in assessing what must be done, so many
of them are allergic to anything that is simply "reserved for future
use."  I had the same trouble when I first started in computers, but I
grew out of it.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 30 Mar 2006 18:12:43 +0200

At 17:44 30/03/2006, John C Klensin wrote:
>If I'm an ISP trying to sell a low-end service to low-end customers 
>at a low  (but still profitable) price, I need to cut customer 
>support costs to the absolute minimum.

Interesting to see the impact of a longer datacom societal culture. 
This may give an indication on the future US trend?

In France you pay the phone support by the minute. A telephone charge 
system inherited from Minitel, and "Audiotel". There are different 
rates which must be advertised. The on-line wait of the support was 
charged. Since Jan 1st, you pay the time you get actual support on line.

Rate for free telephone nationwide + ADSL is 24.5 euro or less. There 
start being free telephone international. Rates use to be 29.95 euro 
when including either TV or free support. Dedicated IPv4 are 
possible. Specialised pro ISP offer IPv6/IPv4 ADSL for around twice 
that price plus free email support and real hosting and emails. You 
can chose not to pay a Telco anymore, just the ISP. After six months 
with a Telco which installs the line. This is transition while ISP 
have not organised the line installation or WI-Max access.

The interest is certainly to provide bundled IPv6 numbers for free. 
This was the underlying intent in a questionnaire of the Regulation 
Authority last year. Increasingly we use coreboxes (smart home 
routers, NAT+ by ISPs). The trend is probably towards an interbox 
network as they become more and more intelligent and powerful.

Most of the mobile subscription offer one to three free numbers. So 
you can plug your home number on the net, make you home number free 
from you mobile and phone to fixed phones for free. I suppose we will 
soon see a box permitting to establish conference calls whcih will 
permit to call mobiles for far less than an SMS.
jfc

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Thu, 30 Mar 2006 19:08:51 +0200

> routers and routing protocols.

The problem with not doing so is that a 128-bit address doesn't
provide anything even remotely close to 2^128 addresses.

You have to choose what you want.

> routing advertisements would be impossible.  It doesn't scale!

Variable address length scales, and it never runs out of addresses,
but nobody wants to do that, even though telephones have been doing it
for ages.

> why we try to use hierarchical addressing even at the cost of numbering
> space.

In that case, assign addresses to points in space, instead of devices.
An office occupying a given plot of land will have an IP address space
that is solely a function of the space it occupies.  Routing would be
the essence of simplicity and blazingly fast.

> routing much easier and more deterministic.

With a variable address length that can extend infinitely at either
end, the address space would never be exhausted.  That's how
telephones work.

> moves. So what. We already have DHCP.  Cell phones do a handoff

I agree.  We also have DNS.

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Thu, 30 Mar 2006 19:11:15 +0200

> having to deal with the problems caused by the NATs?

Sure, and the reply is "I'm sorry, but we don't support multiple
computers on residential accounts."

---

From: Austin Schutz <[email-masked]>
Date: Thu, 30 Mar 2006 11:02:13 -0800

> provide anything even remotely close to 2^128 addresses.

	But this has been known all along. It's a feature, not a bug.
If we "throw away" the last 64 bits we are left with 2**64 addresses,
which is obviously what was intended from the beginning.
	Allocating to ISPs on /48 or so boundaries then maps roughly to
ipv4 /16s which are often handed out now. If a /8 in v4 space gets parceled
out by the registries in a matter of months, a /40 in v6 should last the same.
Following that logic, a /32 in v6 space should last as long as /0 in v4
space.
	The current v4 /0 has lasted for some time now, it's difficult to
envision a time where we would be burning through space so fast that /32s
in v6 space wouldn't last months, if not years.
	But for argument's sake, let's say a /32 lasts one day at some point in
the dim future. This gives us 2 ** 32 days before we run out. not too bad for
those of us not realistically having much of a chance to live beyond 2 ** 15 or
so.
	If we "throw away" additional bits for other engineering purposes
the number of days would be 2 ** (32 - wasted bits). If we waste a full
half of those bits bits we're down to 2 ** 16 days (about 180 years).
	Again, that assumes we'd burn what is equivalent to a v4 /0
every single day for 180 years. Maybe it will become a problem when everyone
has addressable nanocytes in their bloodstream. But I have a hard time seeing
how it could be described as shortsighted.

> the essence of simplicity and blazingly fast.
	Routing doesn't (and will never) work that way. Much like with
airlines, the cost of a path is more complex than mere distance.

> end, the address space would never be exhausted.  That's how

	That would be an alternative, certainly. I'm not sure how excited
to get about a 1 byte payload needing 1000 bytes of header, but I'm sure
it's possible.
	Is it worth throwing away the current post-v4 solution? Certainly
something to consider over the next 180 years.

	Austin

---

From: Austin Schutz <[email-masked]>
Date: Thu, 30 Mar 2006 12:13:47 -0800

This is much less time than I have seen in previous reports. If
this is accurate and consistent there is a greater problem than I had
previously thought.
	If that is indeed the case then the "enhanced nat" road for ipv6
begins to make much more sense, even in the nearer term.

	Austin

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 30 Mar 2006 23:26:40 +0200

> this is accurate and consistent there is a greater problem than I had

You may want to look at Geoff's reports from 2003 and 2005 (and  
observe the difference between the two). Between 2003 and 2006 the  
growth was much larger than before 2003.

As for accuracy: the numbers keep jumping up and down so you can  
pretty much massage them in either direction. These are the number of  
addresses the RIRs allocated to (mostly) ISPs per month for 2005 and  
2006, compiled from the stats published on their FTP sites:

  9.26 M  2005-01
25.16 M  2005-02
17.24 M  2005-03
24.96 M  2005-04
16.67 M  2005-05
16.12 M  2005-06
11.11 M  2005-07
16.92 M  2005-08
  8.80 M  2005-09
  9.89 M  2005-10
  5.78 M  2005-11
  6.62 M  2005-12
  8.95 M  2006-01
11.88 M  2006-02
14.59 M  2006-03

There are now 1428 million addresses still free, give or take one or  
two /8s because of IANA/ARIN inconsistencies. So we can interpret  
this as:

- maximum was 26.16 million/month, which gives us another 57 months
- average was 13.6 million/month, which gives us another 105 months
- average when ignoring bottom and top 3 values was 12.8, 111 months

But that's without accelerating growth, which certainly has been the  
trend most of the time: since 1995, 7 out of 11 years saw more new  
IPv4 addresses deployed than the year before, 3 less. Unfortunately,  
the only way to discern a quantifiable trend here involves so much  
smoothing of the data that the results become meaningless, IMO. That  
said, with no growth in address usage, we'll be out in 2015 and since  
1997, there has always been growth over any three year period. With  
_any_ growth we'll be out of IPv4 addresses in less than 9 years. It  
will take something as big as the deployment of CIDR to get us off  
that track. And no, NAT doesn't even come close. (We went from 211 M  
in 1991 to 63 M in 1994, since 1997 the biggest drop was about 25% in  
one year that was made up for the year after that both in 1999 and  
2002.)

There are plenty more interesting data points, such as the  
observation that even though China and India are similar in  
population, China has 77 million IPv4 addresses (just under the UK  
and just above Canada) and India 6 million (just under Denmark and  
just above Hong Kong). There is only one country with more addresses  
per capita than the US (~4): the Vatican (8192 addresses for 1000  
inhabitants). And even though the US tops the absolute and per capita  
lists of address space holders, it still received the most addresses  
of any country in 2005: more than the numbers two (Japan) and three  
(China) together.

> begins to make much more sense, even in the nearer term.

I remember someone saying something about enhanced NAT here a few  
days ago but I can't find it... What is it and what does it have to  
do with IPv6?

---

From: Peter Dambier <[email-masked]>
Date: Thu, 30 Mar 2006 23:34:56 +0200

> begins to make much more sense, even in the nearer term.

I am afraid the problem is even bigger.

I have seen again and again that cable providers are giving out
ip-addresses in the 10.0.0.0/8 area to save ip address space.

Not to mention wireless hotspots. The hotspots I have been playing
with own only a single one ip-address.

You notice something is awfully wrong, when your VoIP phone is not
working but your neighbar keeps telling you, his skype does.

-- 
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [email-masked]
mail: [email-masked]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/

---

From: John C Klensin <[email-masked]>
Date: Thu, 30 Mar 2006 16:48:55 -0500

> providers as well as heavy users rip all the benefits.

Peter,

I was describing the facts of what is going on, rather than the 
causes.

That said, based on some experience on both the telco and ISP 
sides of things, I believe your analysis is incorrect in a 
number of important ways, starting with the difficulties of 
applying a settlement model that assumes that value accrues to 
the caller to today's Internet.

    john

---

From: Austin Schutz <[email-masked]>
Date: Thu, 30 Mar 2006 14:42:28 -0800

> days ago but I can't find it... What is it and what does it have to  

	It was a term Keith Moore used to describe the addition of
ipv6 capability to NAT devices. Not intended as a real term, merely
a marketing name to explain to the end user the benefit of having
ipv6 capability.

	If address space does indeed burn that quickly, ISPs will start to
realize they can't sell additional IP addresses as a way of making a quick
profit. Those with dwindling address pools will begin to demand proper
ipv6 support from router vendors to offer it at a discounted price (compared
to ipv4) to their customers who are savvy enough to want to run servers but
too cheap to buy ipv4 space at a premium.
	From there it should only be a matter of time. If key applications work
with ipv6 that will probably be adequate to get the ball rolling.

	IIRC there was a similar transition back when virtual web hosting
meant blowing an ip address for every extra domain. After an adequate number
of browsers were upgraded hosting providers made available ip-less virtual
hosts at a heavy discount from ip-burning ones. After a surprisingly short
amount of time the vast majority of browsers were compliant. The final nail was
registries refusing virtual hosting as an excuse to justify allocations.
That's not news to most here, but I definitely see the similarity in the
situation.

	Austin

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 31 Mar 2006 05:36:30 +0200

> But this has been known all along. It's a feature, not a bug.

Yeah, right.

> which is obviously what was intended from the beginning.

And when you allocate bit fields in the remaining 64 bits, you exhaust
that as well.

> envision a time where we would be burning through space so fast that
> /32s in v6 space wouldn't last months, if not years.

The inability to envision things is the root of the problem.

> But for argument's sake, let's say a /32 lasts one day at some point
> in the dim future. This gives us 2 ** 32 days before we run out. not
> too bad for those of us not realistically having much of a chance to
> live beyond 2 ** 15 or so.

More bogus math.  Every time someone tries to compute capacity, he
looks at the address space in terms of powers of two.  Every time
someone tries to allocate address space, he looks as the address space
in terms of a string of bits.  Since the space is allocated as bit
fields, it is exhausted in linear time, even though capacity
projections are based on an exponential space.  For this reason, the
address space always comes up too short, too soon.  The real mystery
is that this seems to surprise people who should know better.

> half of those bits bits we're down to 2 ** 16 days (about 180 years).

Yes, I know how these calculations work.  See above.

> every single day for 180 years.

It doesn't matter how fast we "burn" a v4 /0, because the space is
exhausted by encoding information into the address and allocating bit
spans in the address, not by actually handing out addresses.

> airlines, the cost of a path is more complex than mere distance.

The cost of a processor will always be high and it will always fill
three seven-foot-high cabinets, therefore all computers will always be
timesharing systems. There's no need to imagine desktop computers;
computing doesn't (and will never) work that way.  We should prepare
for the future of dumb terminals, which will eventually be everywhere
(in every home and office).

Do you see the problem with making predictions about the future?

> to get about a 1 byte payload needing 1000 bytes of header, but I'm sure

It would only need a thousand bytes if it were being routed to the
other side of the universe.

> Is it worth throwing away the current post-v4 solution?

Throwing away a few years' work for something that makes virtually no
assumptions about the future?  Yes, it might well be worth it.  It
would have been worth it if it had been done that way in the first
place, too.

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 30 Mar 2006 20:43:14 -0600

Thus spake "Anthony G. Atkielski" <[email-masked]>
> counting it as pure address space is dangerous.

An IPv4/6 address is both a routing locator and an interface identifier. 
Unfortunately, the v6 architects decided not to separate these into separate 
address spaces, so an address _must_ contain routing information until that 
problem is fixed.  It doesn't seem to be likely we'll do so without having 
to replace IPv6 and/or BGP4+, and there's no motion on either front, so 
we're stuck with the locator/identifier problem for quite a while.

> "planning" for something they can't even imagine?

That's why 85% of the address space is reserved.  The /3 we are using (and 
even then only a tiny fraction thereof) will last a long, long time even 
with the most pessimistic projections.  If it turns out we're still wrong 
about that, we can come up with a different policy for the next /3 we use. 
Or we could change the policy for the existing /3(s) to avoid needing to 
consume new ones.

If IPv6 is supposed to last 100 years, that means we have ~12.5 years to 
burn through each /3, most likely using progressively stricter policies. 
It's been a decade since we started and we're nowhere near using up the 
first /3 yet, so it appears we're in no danger at this point.  Will we be in 
50 years?  None of us know, which is why we've reserved space for the folks 
running the Internet then to make use of -- provided IPv6 hasn't been 
replaced by then and making this whole debate moot.

> they'd work just as well for the Internet, if only someone had taken

Variable-length addresses only work if there is no maximum length.  E.164 
has a maximum of 15 digits, meaning there are at most 10^15 numbers.  Here 
in +1 we only use eleven digit numbers, meaning we're burning them 10^4 
times as fast as we could.  That's not a great endorsement.

Also, telephone numbers have the same locator/identifier problem that IPv4/6 
addresses do.  In fact, IPv6's original addressing model looked strikingly 
similar to the country codes and area/city codes (aka TLAs and NLAs) that 
you're apparently fond of.

Even OSI's "variable length" addresses had a maximum length, and most 
deployments used the maximum length; they degenerated into fixed-length 
addresses almost immediately.

> It's a good example of waste that results from short-sightedness.  It

The difference is that in IPv6, it's merely a convention and implementors 
are explicitly told that they must not assume the above boundaries.  In 
IPv4, it was hardcoded into the protocol and every implementation had to be 
replaced to move to VLSM and CIDR.

Conventions are for human benefit, but they can be dropped when it becomes 
necessary.  Folks who use RFC 1918 space almost always assign /24s for each 
subnet regardless of the number of hosts; folks using public addresses used 
to do the same, but instead now determine the minimum subnet that meets 
their needs.  Hopefully the conventions in IPv6 won't be under attack for a 
long time, but if they need to go one day we can drop them easily enough.

>> 64, you can subdivide it yourself and still have four billion times

Not at all.  You'd still have one address per host, you'd just move the 
subnet boundary over a few bits as needed.  With the apparent move to random 
IIDs, there's no reason to stick to /64s for subnets -- we could go to /96s 
for subnets without any noticeable problems (including NAT).

The RIRs could also change policies so that /32 and /48 are not the default 
allocation and assignment sizes, respectively.  That is also another 
convention that we could easily dispense with, but it saves us a lot of 
paperwork to abide by it as long as it doesn't cause problems.

> use."  I had the same trouble when I first started in computers, but I

The folks who designed IPv4 definitely suffered from that problem.  The 
folks who designed IPv6 might also have suffered from it, but at least they 
were aware of that chance and did their best to mitigate it.  Could they 
have done better?  It's always possible to second-guess someone ten years 
later.  There's also plenty of time to fix it if we develop consensus 
there's a problem.

S

Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 30 Mar 2006 20:43:14 -0600

> address space will be exhausted soon enough.

I once read that engineers are generally incapable of designing anything 
that will last (without significant redesign) beyond their lifespan. 
Consider the original NANP and how it ran out of area codes and exchanges 
around 40 years after its design -- roughly the same timeframe as the 
expected death of its designers.  Will IPv6 last even that long?  IMHO we'll 
find a reason to replace it long before we run out of addresses, even at the 
current wasteful allocation rates.

> 125-bit address space, or

That's one way of looking at it.  The other is that even with just the 
currently allocated space, we can have 35,184,372,088,832 sites of 65,536 
subnets of 18,446,744,073,709,551,616 hosts.  Is this wasteful?  Sure.  Is 
it even conceivable to someone alive today how we could possibly run out of 
addresses?  No.

Will someone 25 years from now reach the same conclusion?  Perhaps, perhaps 
not.  That's why we're leaving the majority of the address space reserve for 
them to use in light of future requirements.

> Why is this so difficult for people to understand?

And sequential assignments become pointless even with 32-bit addresses 
because our routing infrastructure can't possibly handle the demands of such 
an allocation policy.  The IETF has made the decision to leave the current 
routing infrastructure in place, and that necessitates a bitwise allocation 
model.

Railing against this decision is pointless unless you have a new routing 
paradigm ready to deploy that can handle the demands of a non-bitwise 
allocation model.

Why is this so difficult for you to understand?

> You're doing it again.  It's not 45 bits; it's a factor of

I take it you mean "the blick of an eye" to mean a span of decades?  That is 
not the common understanding of the term, yet that's how long we've been 
using the current system and it shows absolutely no signs of strain.

> Do engineers really study math?

To achieve bitwise aggregation, you necessarily cannot achieve better than 
50% use on each delegation boundary.  There are currently three boundaries 
(RIR, LIR, site), so better than 12.5% address usage is a lofty goal. 
Again, if you want something better than this, you need to come up with a 
better routing model than what we have today.

(And then throw in the /64 per subnet and you're effectively wasting 100% of 
the address space anyways, so none of this matters until that's gone)

> slice required to handle current requirements?

If EUI-64 addresses somehow go away, and there's no sign they will, we 
already have another mechanism ready for how to assign addresses within a 
subnet.  In fact, it appears it's even the default in the next Windows.

If/when it ever matters how much address space we assign to subnets, we 
already know how to determine the necessary size and assign just that. 
Until we do need to do that (if ever), we can use the /64 convention without 
concerns.  It's no big deal to change later if needed.  In fact, we may end 
up not using that convention at all once IPv6 is actually rolled out to a 
significant part of the 'net.

See above.

> number, depending on how much information you try to encode into the

Again, the current identifier/location conflation combined with the routing 
paradigm leaves us no choice but to encode information into the IP address.

S

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 30 Mar 2006 20:43:14 -0600

See above.

S

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 30 Mar 2006 23:11:28 -0500

> Or we could change the policy for the existing /3(s) to avoid needing to 

I really shouldn't waste my time on this thread; I really do know
better.

You're absolutely right about the /3 business -- this was a very
deliberate design decision.  So, by the way, was the decision to use
128-bit, fixed-length addresses -- we really did think about this
stuff, way back when.

When the IPng directorate was designing/selecting what's now IPv6,
there was a variable-length address candidate on the table: CLNP.  It
was strongly favored by some because of the flexibility; others pointed
out how slow that would be, especially in hardware.

There was another proposal, one that was almost adopted, for something
very much like today's IPv6 but with 64/128/192/256-bit addresses,
controlled by the high-order two bits.  That looked fast enough in
hardware, albeit with the the destination address coming first in the
packet.  OTOH, that would have slowed down source address checking
(think BCP 38), so maybe it wasn't a great idea.

There was enough opposition to that scheme that a compromise was
reached -- those who favored the 64/128/192/256 scheme would accept
fixed-length addresses if the length was changed to 128 bits from 64,
partially for future-proofing and partially for flexibility in usage.
That decision was derided because it seemed to be too much address
space to some, space we'd never use.

I'm carefully not saying which option I supported.  I now think, though,
that 128 bits has worked well.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Theodore Ts'o <[email-masked]>
Date: Thu, 30 Mar 2006 23:39:46 -0500

On Fri, Mar 31, 2006 at 05:36:30AM +0200, Anthony G. Atkielski wrote:
> in terms of a string of bits.  

Anthony,

	You've been making the same point over and over (and over)
again.  It's probably the case that people who will be convinced by
your arguments, will have accepted the force of your arguments by now.
For people who don't accept your arguments, they are not likely to be
swayed by a "last post wins" style of argumentation.

	May I gently suggest that you stop and think before deciding
whether you need to respond to each message on this thread, and
whether you have something new and cogent to add, as opposed to
something which you've said already, in some cases multiple times?

	Thanks, regards,

						- Ted

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 31 Mar 2006 07:03:15 +0200

Stephen Sprunk writes:

> And sequential assignments become pointless even with 32-bit
> addresses because our routing infrastructure can't possibly handle
> the demands of such an allocation policy.

They are pointless for the reasons you state, but they are also the
only way to get 2^128 addresses out of 128 bits.  Anything else
encodes information in the address and reduces the usable address
space exponentially.

> Railing against this decision is pointless unless you have a new
> routing paradigm ready to deploy that can handle the demands of a
> non-bitwise allocation model.

The bitwise allocations I'm hearing about are not based on routing.

> I take it you mean "the blick of an eye" to mean a span of decades?

At best.

> That is not the common understanding of the term, yet that's how
> long we've been using the current system and it shows absolutely no
> signs of strain.

So IPv6 is not needed?

> To achieve bitwise aggregation, you necessarily cannot achieve
> better than 50% use on each delegation boundary. There are currently
> three boundaries (RIR, LIR, site), so better than 12.5% address
> usage is a lofty goal. Again, if you want something better than
> this, you need to come up with a better routing model than what we
> have today.

I did, but nobody was interested.

> Again, the current identifier/location conflation combined with the
> routing paradigm leaves us no choice but to encode information into
> the IP address.

In that case, any predictions of longevity for the system based on the
address space providing 2^n addresses for n bits are invalid.
Strangely, such predictions seem to be almost exclusively based on
this, and thus are necessarily wrong.

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 31 Mar 2006 07:12:49 +0200

> An IPv4/6 address is both a routing locator and an interface identifier.

And so engineers should stop saying that n bits of addressing provides
2^n addresses, because that is never true if any information is
encoded into the address.  In fact, as soon as any information is
placed into the address itself, the total address space shrinks
exponentially.

> Unfortunately, the v6 architects decided not to separate these into
> separate address spaces, so an address _must_ contain routing
> information until that problem is fixed. It doesn't seem to be
> likely we'll do so without having to replace IPv6 and/or BGP4+, and
> there's no motion on either front, so we're stuck with the
> locator/identifier problem for quite a while.

Then we need to make predictions for the longevity of the scheme based
on the exponentially reduced address space imposed by encoding
information into the address.  In other words, 128 bits does _not_
provide 2^128 addresses; it does not even come close.  Ultimately, it
will barely provide anything more than what IPv4 provides, if current
trends continue.

> Or we could change the policy for the existing /3(s) to avoid needing to

Or simply stop trying to define policies for an unknown future, and
thereby avoid all these problems to begin with.

> first /3 yet, so it appears we're in no danger at this point.

As soon as you chop off 64 bits for another field, you've lost just
under 100% of it.

> Variable-length addresses only work if there is no maximum length.

Ultimately, yes.  But there is no reason why a maximum length must be
imposed.

> E.164 has a maximum of 15 digits, meaning there are at most 10^15
> numbers. Here in +1 we only use eleven digit numbers, meaning we're
> burning them 10^4 times as fast as we could. That's not a great
> endorsement.

Telephone engineers make the same mistakes as anyone else; no natural
physical law imposes E.164, however.

> Also, telephone numbers have the same locator/identifier problem
> that IPv4/6 addresses do. In fact, IPv6's original addressing model
> looked strikingly similar to the country codes and area/city codes
> (aka TLAs and NLAs) that you're apparently fond of.

Maybe the problem is in trying to make addresses do both.  Nobody
tries to identify General Electric by its street address, and nobody
tries to obtain a street address based on the identifier General
Electric alone.

> The difference is that in IPv6, it's merely a convention ...

Conventions cripple society in many cases, so "merely a convention"
may be almost an oxymoron.

> later.  There's also plenty of time to fix it if we develop consensus

Sometimes the most important design criterion is ignorance.  In other
words, the best thing an engineer can say to himself in certain
aspects of design is "I don't know."

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 31 Mar 2006 07:17:01 +0200

Theodore Ts'o writes:

> again.

To some, perhaps.  I'm not so sure that it has yet been made even once
to others.

> It's probably the case that people who will be convinced by your
> arguments, will have accepted the force of your arguments by now.
> For people who don't accept your arguments, they are not likely to
> be swayed by a "last post wins" style of argumentation.

It depends.  People with an emotional attachment to a specific notion
will never been convinced otherwise, but people who simply don't
understand something may change their mind once they understand.

> something which you've said already, in some cases multiple times?

May I gently suggest that you use the delete key on your keyboard for
messages that you don't want to see?  I doubt that bandwidth is a
problem at MIT.  It has always worked for me, and I'm constrained by
much more limited bandwidth.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 31 Mar 2006 08:46:00 +0300 (EEST)

>> Why is this so difficult for people to understand?
..
> Why is this so difficult for you to understand?

Feeding trolls is not very useful.. please at least keep him in Cc: so 
I don't have to see the messages.. :-)

I've yet to see Anthony make any useful contribution to the IETF 
(various rants on the IETF list don't count).

Perhaps we should just ban him from the list.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Dave Cridland <[email-masked]>
Date: Fri, 31 Mar 2006 10:31:26 +0100

> understand something may change their mind once they understand.

I do understand your argument, and you're correct in all its 
assertions, but not the conclusion. I suspect that's the case for 
everyone at this point.

You state, loosely, that 128 bits will not realistically yield 2**128 
addresses, which is entirely true. It's been pointed out that IPv6 
wasn't designed for that, instead, it was designed to yield 2**64 
subnets, and even so, it's acknowledged that a considerable amount of 
that space will be wasted. People have agreed with this, but pointed 
out that the "subnet" level can be moved down, since we're only using 
an eighth of the available address space.

You also state that the relatively coarse prefix-based allocation 
will yield higher wastage of addresses, and increasing the corseness 
of this allocation reduces available address space exponentially - 
again, this is at least loosely true. I'm not utterly sure that 
"exponential" is the correct word to use here, but I'll accept it in 
lieu of any other term. Many people have agreed with the implications 
of this, suggesting that a jump from /64 to /48 is too much, and I'm 
inclined to agree - the cost of renumbering is not high, and given 
autoconfiguration, is virtually zero.

Your conclusion, however, is that we should be switching to a 
zero-wastage allocation mechanism preferably based on variable 
bitlength addresses. In response to this, several people have 
commented that this is unworkable using both current hardware and any 
hardware predicted to be available within the next few years. I don't 
know about that, but I'm prepared to accept that opinion.

There's an additional unanswered question your argument has, which is 
whether the - very real - issues you're pointing out with prefix 
based allocations will cause actual operational problems within a 
timeframe short enough for anyone to worry over for a few decades, 
and - a related issue - would these problems hit sufficiently quickly 
that a replacement for IPv6 couldn't be developed in time?

Dave.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 31 Mar 2006 12:12:09 +0200

> 128-bit, fixed-length addresses -- we really did think about this

I reviewed some old IPng mail archives last year and it was very  
illuminating to see people worry both about stuff that is completely  
a non-issue today and stuff that's still as big a problem as ever  
today. However, a lot has changed in over a decade, and even if fixed  
length addresses was the right answer then (which I'm not necessarily  
conceding), that doesn't necessarily make it the right answer today.

> there was a variable-length address candidate on the table: CLNP.

I'm no OSI expert, but what I gather is that within a domain, all  
addresses must be the same length, so variable length addressing  
doesn't really work out in practice.

> It was strongly favored by some because of the flexibility; others  
> pointed

I guess that argument can be made for the traditional "this address  
is X bits and here are enough bytes to hold them" type of variable  
length address encoding that we also use in BGP, for example. But  

> (think BCP 38), so maybe it wasn't a great idea.

On the other hand having a protocol chain in IPv6 makes checking TCP/ 
UDP ports a nightmare, so there's more than enough precedent for  
that. That's one lesson we can learn from the OSI guys: the port  
number should really be part of the address.

A way to encode variable length addresses that would presumably be  
even easier to implement in hardware is to split the address in  
several fields, and then have some bits that indicate the presence/ 
absence of these fields. For instance, the IPv6 address could be 8 16- 
bit values. The address 3ffe:2500:0:310::1 would be transformed into  
3ffe-2500-0310-0001 (64 bits) with the control bits 11010001  
indicating that the first, second, fourth and eighth 16-bit values  
are present but the third and fifth - seventh aren't. It should be  
fairly simple to shift the zero bits in and out in hardware so the  
full maximum length version of the address can be available in places  
where that's convenient.

And in reaction to other posts: there is no need to make the maximum  
address length unlimited, just as long as it's pretty big, such as  
~256 bits. The point is not to make the longest possible addresses,  
but to use shorter addresses without shooting ourselves in the foot  
later when more address space is needed. For instance, I have a /48  
at home and one for my colocated server. For that server, I could use  
the /48 as the actual address for the server, or add a very small  
number of bits. At home, stateless autoconf is useful so 94 bits  
would be sufficient (/48 + 46 bit MAC address), maybe add a couple of  
bits for future subnetting. So the server address would be 7 bytes  
(with the length field) rather than 16 and the laptop address 13,  
saving 12 bytes per packet between the two over today's IPv6...

> that 128 bits has worked well.

It would be rather disastrous if 128 bits didn't work well at this  
stage.  :-)

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 31 Mar 2006 14:38:33 +0200

At 04:43 31/03/2006, Stephen Sprunk wrote:
>If IPv6 is supposed to last 100 years, that means we have ~12.5 
>years to burn through each /3, most likely using progressively 
>stricter policies.

I suppose you want to say 16,66 years (only 5 /3 are available). This 
is a way of seeing things.
This means that there are still 4 years to go for the next /3 to 
start being used.
It seems a good forecast, in line with observation and demand. But it 
means that decisions are to be taken now.

>There's also plenty of time to fix it if we develop consensus 
>there's a problem.

- don't you think it is clear now there is a market rough consensus?
- what makes you believe that the IETF is the proper place to take 
care of such a "fix"? I love competition when it makes sense. I 
certainly would favor the IETF and the ITU to best compete for an 
IPv6 service the Internet users dearly miss. Before we have other 
grassroots solutions (are you sure that NATs are the only solution?).

There are obviously two schools about IPv6 numbering:
- "what exists is nearly perfect and we need to implement it to prove 
it, but we do not know how to get it implemented."
- "what exists is wrong and this is the reason why it is not implemented."

IMHO both schools should be given an equal chance to show they are 
right. And probably to address different types of problems.

BTW, deploying IPv6, I suggest that every new ICANN TLD should only 
accept registrations with IPv6 addresses (why new TLDs if not for a 
new netwok?). The day ".xxx" is accepted the network would turn IPv6.
jfc

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 31 Mar 2006 18:52:16 +0200

> assertions, but not the conclusion. I suspect that's the case for 

Not as long as I still see people claiming that 128 bits will provided
2^128 addresses _and_ that it can still be divided into multiple bit
fields.

> You state, loosely, that 128 bits will not realistically yield
> 2**128 addresses, which is entirely true.

Yes.

> It's been pointed out that IPv6 wasn't designed for that, instead,
> it was designed to yield 2**64 subnets, and even so, it's
> acknowledged that a considerable amount of that space will be
> wasted. People have agreed with this, but pointed out that the
> "subnet" level can be moved down, since we're only using an eighth
> of the available address space.

I don't think many people appreciate just how quickly such policies
can exhaust an address space--mainly because they keep emphasizing
that 2^n addresses are available in n bits, apparently oblivious to
the multiple factors that will waste most of the addresses.

> bitlength addresses.

That is one option.  Another is to stop trying to plan the entire
future of IP addressing today.  As I've said, just adding one more bit
to 32-bit addresses would hold the Internet together for years to
come.  Immediately blowing 2^125 addresses is absurd.

> In response to this, several people have commented that this
> is unworkable using both current hardware and any hardware
> predicted to be available within the next few years. I don't

I'll accept the opinion, but as long as it remains opinion, I can
continue to assert the contrary.  I don't see any insurmountable
obstacle that would prevent this type of implementation.  Indeed, I
should think it would greatly simplify routing.

> that a replacement for IPv6 couldn't be developed in time?

In this respect I'm going by past history.  As I've said, engineers
routinely underestimate capacity and overestimate their own ability to
foresee the future, often with expensive and defect-ridden results.
The Internet gets bigger all the time, and the cost of these mistakes
will be astronomically high in the future--more than high enough to
justify changing this mindset.  I'm just trying to limit the damage by
suggesting changes as early as possible.

Has anyone else noticed that the simplest standards tend to last the
longest, and that complex, committee-designed standards are often
obsolete even before the 6000-page specifications are printed and
bound?  I see that SMTP is still around, but I don't see too many
people using X.400.  I see people writing code in C, but not in Ada.

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 31 Mar 2006 18:56:21 +0200

Iljitsch van Beijnum writes:

> ~256 bits.

But there isn't much reason to not make it unlimited, as the overhead
is very small, and specific implementations can still limit the actual
address length to a compromise between infinity and the real-world
network that the implementation is expected to support.

> The point is not to make the longest possible addresses,
> later when more address space is needed.

Use unlimited-length addresses that can expand at _either_ end, and
the problem is solved.  When more addresses are needed in one
location, you add bits to the addresses on the right; when networks
are combined and must have unique addresses, you add bits on the left.

---

From: Peter Sherbin <[email-masked]>
Date: Fri, 31 Mar 2006 10:14:18 -0800 (PST)

> Immediately blowing 2^125 addresses is absurd.

We want to network the world inside and around us
and then automate it. IPv6 is timely and suits well
both purposes.

[email-masked]

--- "Anthony G. Atkielski" <[email-masked]>