Subject: RE: Death of the Internet - details at 11

From: "Michel Py" <[email-masked]>
Date: Mon, 12 Jan 2004 15:38:43 -0800

> Tony Hain wrote:
> You won't get the development community to pay attention
> to the simplicity afforded by IPv6 until the IETF stops
> wasting time trying to extend a dead protocol.

If one in {IPv4,IPv6} could be qualified as dead, it's IPv6. If it was
not for IPv4, the majority of this list would not even be able to read
this.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Tue, 13 Jan 2004 09:09:27 -0800

> Hayriye Altunbasak wrote:
> Should not you first investigate the reason why
> IPv6 is not successful in terms of deployment
> (yet)? So that, we won't make the same mistakes
> if the world decides to sth else....

These reasons are well-known and two-fold:

1. It's an investment without any foreseeable ROI:
- Scarcity of IPv4 addresses? Not any time soon and certainly not soon
enough to justify any investment within the next n years.
- Ease of renumbering? A myth.
- Auto-configuration? Not fundamentally a breakthrough over DHCP.
In other words: what is IPv6 going to buy me or my business in the next
n years? Nothing I don't already have with IPv4; why should I invest in
it (especially given the tight finances these days) ?

2. It does not even provide what IPv4 does:
- No multihoming.
- No PA addresses.
- Ni private addresses.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Tue, 13 Jan 2004 11:34:08 -0800

Tony,

> Tony Hain wrote
> Like it or not, we are at the end of the IPV4 road

I think that's where you missed it. We are not. The truth is that the
end of the IPv4 road is in sight; how far away we don't really know, as
looking through the NAT binoculars does not seem to make it closer. How
fast we will be there we don't know either, as the Ferrari we were
driving 3 years ago has run out of gas and we're now traveling in a much
slower bus.

> Anything that comes out of rearchitecting the
> Internet will be at least another 10 year process.

If it's designed as a protocol, likely. If it's designed as a product
with a migration roadmap, not necessarily so. The very flaw in IPv6 is
that it's never been designed as a product that needs to be adopted.

Michel.

---

From: [email-masked]
Date: Wed, 28 Jan 2004 15:20:22 EST

Amen to those words

Wayne

---

From: [email-masked] (Noel Chiappa)
Date: Wed, 28 Jan 2004 17:11:07 -0500 (EST)

> From: John C Klensin <[email-masked]>

    > For _that_ problem, we had a reasonably effective IPv4 solution .. for
    > many years

We only has a "solution" as long as we had a small network. It was not a
solution which would scale. If that was a "solution", then IPv4 is a
"solution" to the need for address space.

    > when we imposed CIDR, and the address-allocation restrictions that went
    > with it, it became impossible for someone to get the PI space that is
    > required ...
    > I'll stipulate this is a routing problem as much, or more, than it is
    > an address-availability problem.

CIDR was always a single set of mechanisms (ubiquitous use of address masks)
which solved two completely separate problems: i) allocation of address space
in finer-grained chunks, to slow the rate of use, and ii) address table
bloat, leading to routing instability. The routing aspect was not an
afterthought or a later discovery, but an integral aspect from the very
beginning. Thinking of CIDR as a address space allocation mechanism is broken.

    > I'll also agree that there appears to be little evidence that IPv6 is
    > significantly more routing-friendly than IPv4

"little" -> "none".

    > any real routing-based solutions that help the one will help the other.

One of the painful pills the WG members have had to swallow is that there *is
no* "routing-based solution" to providing support for wide-spread
multi-homing (at least in anything like the current routing architecture,
i.e. packets which include only source and destintion addresses, as opposed
to a source route).

If you (or anyone else) doesn't understand why, please review the WG mailing
list archives before claiming otherwise.

    >   (i) if any of the options turn out to require an
    >   approach similar to the one that continue to work for
    >   big enterprises with PI space in IPv4, then we are going
    >   to need (lots) more address space.

Since the precursor is not going to happen, we don't need to worry about
the hypothetical consequence.

    > there is very little that we do on the Internet today that require
    > connection persistence when a link goes bad

I made this exact point some time back, and asked if this was therefore
really a requirement, and was told that it was. I remained extremely dubious,
but had no interest (for obvious reasons) in correcting it if wrong.

I will note in passing that if this capability were not really needed, one
might ask why SCTP added it.

    > it may speak to the IETF's sense of priorities that the efforts to
    > which you refer are predominantly going into the much more complex and
    > long-term problem, rather than the one that is presumably easier to
    > solve and higher leverage.

The general approach (of multiple addresses) is the only realistic one. Any
analysis of whether the additional requirement (for connection survivability)
has a reasonable cost/benefit ratio needs to start with this ground truth.

It may be that the differential complexity to go from i) multiple addresses,
and established connections cannot switch, to ii) multiple addresses, and
established connections can switch, is minimal. I can't say; I haven't
bothered to look at the (to me, boring) engineering details.

	Noel

---

From: "Yuri Ismailov (KI/EAB)" <[email-masked]>
Date: Fri, 30 Jan 2004 13:57:16 +0100

However this is only about using multiple addresses.
Is there any concern about mobility between them?
In such case things look much differently, especially if interfaces configured with v6 and v4.
/yuri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Randall R. Stewart (home)
Sent: den 30 januari 2004 13:17
To: Noel Chiappa
Cc: [email-masked]
Subject: Re: Death of the Internet - details at 11

Noel:

Comments in line :->

Noel Chiappa wrote:

>    > Of course, multiple A records works, is out there, and have worked for
>    > years. But they worked better before we introduced routers (i.e., when
>    > the hosts with multiple A records really had interfaces on different
>    > networks). Today, it effectively implies having multiple addresses on
>    > an interface and multiple "local" address prefixes running around on
>    > the same physical LAN segment.
>    > ...
>    > Perhaps more important, as Noel points out, it doesn't scale very well,
>    > at least in terms of the routing fabric.
>
>Sorry? What I said doesn't work for the routing, in terms of scaling to many
>small sites, is for a multi-homed site to have a single address prefix, which
>is then globally advertised. (That's the most common tack for multi-homing
>support in IPv4 to date, which is what you were talking about.)
>
>Having multiple addresses for a host (which has only a single physical
>interface, but which is in a site which is multi-homed) is in fact the only
>approach whose effects on the routing does scale (within anything like the
>current routing architecture, i.e. packets which include only source and
>destination addresses, as opposed to a source route).
>

Or you can use SCTP and have seperate interfaces going to
seperate ISP's and have the transport use them both....

That is how we designed SCTP.....

>
>
>    > as I tried to point out, address preservation policies have had
>    > trickle-down effects that make it impractical for small enterprises.
>
>It is an interesting point (as Daniel Senie also just pointed out) that
>multiple addresses -> faster consumption of the address space.
>
>However, since to avoid a size explosion in the routing tables, those
>multiple addresses do have to be connectivity-dependent (political
>translation - "provider-dependent"), I don't see how address preservation
>policies have made this approach "impractical for small enterprises". My
>understanding of current allocation policies is that ISP's can get enough
>addresses to cover their customers. If company X is a customer of both ISP P
>and ISP Q, I would assume that both P and Q don't have a problem getting
>enough space to cover their customers - including X.
>

Exactly... When I buy two seperate DSL's from two seperate
ISP's the two ISP's hand me an IP address .. they are seperate and
don't break or violate any current address allocation policy.
I don't ask SBC to advertise my speakeasy address... or vice-versa..
instead I let SCTP handle it all...

R

>
>(Or were you speaking of the "one address block, globally advertized"?)
>
>	Noel
>
>
>
>  
>

-- 
Randall R. Stewart
815-477-2127 (office)
815-342-5222 (cell phone)