Subject: Re: breaking the IP model (or not)

From: "J. Noel Chiappa" <[email-masked]>
Date: Tue, 11 Apr 2000 13:10:01 -0400

> From: Erik Fair <[email-masked]>

    > Almost all of the pressure created by the growth of the Internet is
    > on the network operators and their vendors (e.g. router vendors),
    > rather than on the users and the end systems (and the end system
    > vendors

Well, there are rational (?) structural reasons for this. i) There are more
end systems than infrastructure boxes, so it's more work to change the
former. ii) The end system boxes are often under the control of people who
have less technical expertise, contacts, organization, etc than the
infrastructure boxes, so it's more work to change them.

All of which leads to solutions being jammed into the infrastructure boxes,
which are easier to get to, rather than the end system boxes, where it may
be desirable for architectural reasons. I wish a had some idea how to
change this, but I don't (short of finding some killer app and bundling it
with an end system architectural upgrade).

    > So, with nearly all the pressure on the operators and the vendors
    > that serve them, the "solutions" they come up with are necessarily
    > pretty ugly hacks (e.g. NAT, TCP spoofing, Firewalls) because they
    > have to deal with the reality that they can't change the end systems
    > themselves, or require them to be changed.

There's another factor, which is that short-term fixes are less expensive
in the here-and-now than fixes with a longer horizon. You see this effect
operating even in areas that *don't* involve the end systems (e.g. routing).

    > This is a structural problem. Until the situation changes, we're
    > going to keep on seeing ugly hacks that do violence to the Internet
    > architectural model deployed, marketed, touted as "solutions."

In the past, it has been a truism of system architecture that systems
usually die because i) the basic architecture had things missing; ii) the
'improvements' done to rectify these problem are usually poorly
thought-out/intergrated "warts" added by programmers who are new hires and
don't really have the vision/confidence to fundamentally alter things; and
iii) eventually the system crumbles under the addition of all these warts,
and you have to throw it all out and start again from scratch.

What's novel about the Internet is that i) the people making the additions
are not all working for one company, but are a large collection of people
without any central control, and ii) the process of "starting from scratch"
will be even more painful, since you not only have to keep the old system
running, but have it interoperate with the new one while the changeover is
happening. (Think NCP->TCP conversion, but ^69th.)

I'm not sure what the model is to make this happen, but I've come to the
conclusion that the IETF process, as the IETF has evolved, is not the way
to do it.

	Noel

---

From: Greg Skinner <[email-masked]>
Date: Fri, 14 Apr 2000 17:41:19 -0700 (PDT)

Keith Moore wrote:

> it's not at all clear whether NAT provided additional time for
> IPng development or whether such time was really needed.  IPv6 was
> largely developed before NAT enjoyed significant deployment, and
> arguably NAT has delayed adoption of IPv6.  and because of the NAT
> deployment it is now somewhat "untimely" to deploy applications like
> IP telephony.  whereas if IPv6 had been adopted a bit earlier
> (because NAT had not filled the vacuum, so to speak) IP telephony
> would work just fine with it.

True, but you also have to take into account that IPv4 is mature
technology (and was so at the time of NAT deployment).  The user demand
for Internet access made NAT a more attractive avenue because the
industry had confidence that it would work without them having to
make changes.  If you could sell a NAT-compliant box you had an
eager market; not quite so with an IPv6 compliant box.

> of course, IPv6 might have moved along slowly even without NAT.
> but it would probably have moved faster had NATs not existed.

Maybe.  Hard to say.  Depends on how comfortable the industry would
have been with it.

> best thing I can say about NAT is that it motivated me to work on 6to4.

:)

--gregbo

---

From: Greg Skinner <[email-masked]>
Date: Fri, 14 Apr 2000 18:03:12 -0700 (PDT)

Keith Moore wrote:

> perhaps architectural impurity alone shouldn't keep you from doing
> something, but the fact that something violates fundamental design
> assumptions should cause you to do some analysis and hard thinking
> about the likely consequences of using them.  and if you are in the
> business of selling boxes that violate the design assumptions you
> shouldn't misrepresent these to your customers.

True, however I think at least some of the customers are also to blame.
In their haste to get on the Internet they went out and bought NAT boxes
without understanding their limitations.

I hear about this sort of thing even outside of the context of NAT,
e.g. with people who have non-globally routable IP address blocks and
don't understand why they can't reach certain sites.  They then complain
to their ISPs, who point out that their service does not guarantee
global routing.

--gregbo