So why is "IPv4 with longer addresses" a problem anyway?

[Benedikt Stockebrand]

Hi Doug and list (again^2),

Doug Barton <dougb at dougbarton.us> writes:

> On Mon, 24 May 2010, Benedikt Stockebrand wrote:
>>
>> Maybe.  But maybe I've seen too many people who want IPv6 to be
>> nothing more than "IPv4 with longer addresses".
>
> I'm responding to this bit separately because I think it deserves its
> own topic. I hear this all the time, and I'm genuinely curious about
> the answer to this question.
>
> Given all the churn in network protocols that was happening in the
> 90's already I have a theory that if "we" had simply done "IPv4 with
> longer addresses" in the first place that IPNG would have been
> deployed almost immediately and all the energy and drama that's been
> spent on trying to make it more than that could have been better spent
> elsewhere.

I don't think so.  If we had stuck with IPv4 except for the address
size we'd still have, among other issues,

- a maximum of 60 bytes for header options, rather than flexible
  extension headers

- carrying around fragmentation information in every packet even
  though it is barely ever used, rather than a fragmentation extension
  header

- no standardized way to deal with address collisions, rather than
  duplicate address detection

- variable length netmasks as a common misconfiguration issue, rather
  than an implicit /64

- miscalculated netmasks due to the decimal notation, rather than the
  more simple hex-to-binary calculations

- obscure routing problems due to either these miscalculations or
  people trying to use non-monotonous netmasks, rather than using
  prefix lengths only

- IP header checksums that have to be recomputed at every router,
  rather than leaving it to the link layer and transport layer
  pseudo-header mechanisms

- Router side fragmentation as well as path MTU discovery, rather than
  pMTUd only

- An extremely small minimum MTU (296 bytes), rather than 1280

- No link-local scope and subsequent simplifications

- No generally usable anycast but somewhat kludgy or
  application-specific approaches

- Impractical multicast routing, rather than feasible enterprise-wide
  multicast routing.

- Non-global addresses used over and again, causing significant
  problems during mergers and acquisitions (among others), rather than
  unique-local addresses

- A dense address space which takes significantly more effort to
  manage

- A rather historically grown ICMP type/code allocation, rather than a
  cleaned-up one

- Loose source routing

- No jumbograms

- The need for VRRP, HSRP or passive routing daemons on all clients to
  set up redundant routers

and whatever else I would have found in the remaining two thirds of a
training presentation on IPv6 protocols I wrote for a
protocol-oriented customer.

Generally speaking, IPv6 gets rid of a significant number of
limitations of IPv4.  Many of them are "minor", but in sum they do
make a significant difference.  

The one many people find difficult to come to grips with is the sparse
address space, which simplifies configuration, gets rid of a number of
security issues and significantly simplifies address management.

> So my question is, other than longer addresses, what are the benefits
> to IPv6 that I can point clients to which will help them justify the
> expense of the upgrade?

The benefit I can point out to customers even without significant
technical background is this one: In the traditional telephony world
we are normally talking about an end-to-end availability around five
niners (99.999%, or ~4.5 minutes/year downtime) including scheduled
downtimes.  In the IP world we are a long way away from that.  IPv6
offers so many "minor" simplifications and improvements that offer a
significant increase in overall reliability.

Aside from that, once Microsoft stops supporting XP the majority of
machines will take extra effort and cost to be run with IPv4 while at
the same time some new functionality won't be available.


Cheers,

    Benedikt

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

Benedikt Stockebrand, Dipl.-Inform.   http://www.benedikt-stockebrand.de/