Subject: Re: Internet Architecture (was US DoD and IPv6)

From: [email-masked] (Noel Chiappa)
Date: Fri, 8 Oct 2010 12:54:20 -0400 (EDT)

{'Borrowing' a new, more appropriate Subject: from a private reply...}

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

    > What does this say about the IETF and how we make decisions? Does that
    > need adjusting?

Perhaps, but even I shrink from tackling that particular windmill!

    > while ... recriminations based on hindsight may be satisfying in some
    > ways, the question is what to do going forward. 

I couldn't agree with your latter point more.

    > There are communities out there who believe that we have managed to
    > "prove" that datagram networks, with packet-level routing, are a
    > failure at scale and that we should be going back to an essentially
    > connection-oriented design at the network level.

I (perhaps obviously) think that's a rash conclusion: the circa 1975 Internet
architecture was never intended to grow to this size, and that it has done so
at all (albeit via the use of a number of hacks, some merely kludgy, others
downright ugly) is a testament to how well the basic concept (of unreliable
packets, and minimal state in the network) works.

I do think that the architecture does require some work, though, and for a
number of reasons. For one, the real requirements have become more complex as
the network has grown, and a number that have arrived (e.g. provider
independence for users; the need for ISP's to be able to manage traffic
flows; etc) aren't really handled well (or at all) by the existing
architecture. For another, we need to bring some order to the cancerous chaos
that has resulted from piecemeal attempts to deal with the previous point.
Finally, it's a truism of system design that arrangements that work at one
order of scale don't at another, and as the network has grown beyond almost
our wildest expectations - and certainly larger than it was ever designed to
- I think we're seeing that too.

    > If not, then there are other focused discussions that would be helpful.
    > The latter discussions that have almost started in this and related
    > threads, but have (I believe) gotten drowned out by the noise, personal
    > accusations about fault, and general finger-pointing.

Well, sometimes one has to clear the air (or underbrush, if you will), and
get everyone's minds open, before one can make forward progress. But I agree,
'hah-hah, your end of the ship is sinking' rapidly becomes totally
unproductive.

    > How would you propose moving forward?

Well, IMO there are a number of things we need to do, which can be done all
in parallel.

The first is to be honest with ourselves, and with the people out there who
depend on us to set direction, about what's really likely to happen out in
the network; e.g. a very long period during which we are stuck with multiple
naming realms with various kinds of translators (NATxx) gluing them together.

This whole 'don't worry, everything will be fine' schtick has got to go -
we're now in what I call "The Emperor's New Protocol" land, where (almost)
everybody knows the theoretical plan isn't going to work, and major revisions
are needed, but nobody wants to come right out and say so formally.

We need to do that.

I think a group (set up by the IAB, who make these kind of pronouncements)
should sit down and draw up a _realistic_ picture of what the future over the
next couple of years (say, up to 5 years out - 5 only, because of a second
parallel effort, below) is likely to be, and get that out, so people have a
realistic appraisal of how things stand (and restore a little bit of the I*'s
credibilty, in the process).

That group (or perhaps a sister group) should produce a formal statement
covering the implications for IETF work of that present/future; i.e. about the
_existing_ architectural environment in which the protocols the IETF designs
have to operate, and thus have to be designed for. E.g. a formal IETF policy
statement 'all IETF protocols MUST work through NAT boxes'. Etc, etc.

The second is to set up a group (and again, this is the IAB's job) to try and
plan some sort of evolutionary architectural path, which would have two
phases: i) to survey all classes of stakeholders (ISP's, content providers,
users) to see what the network needs to be able to do that it can't now, and
ii) provide both a) an architecture that meets those needs, and b) a
_realistic_ plan for getting there. Realistic in economic, interoperability,
etc terms - all the things we have learned (painfully) are so critical to the
viable roll-out of new stuff.

Do note that that effort implies that the current solution _doesn't_ provide
all those things. So we might as well swallow hard and admit _that_ publicly
too.

Whether all the above is politically feasible in the current IETF - who knows?
If not, it's back to 'The Emperor's New Protocol' for another year or so, I
guess, by which time the environment may be a bit more receptive.

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Fri, 8 Oct 2010 15:37:25 -0400 (EDT)

> From: Dave Cridland <[email-masked]>

    > So currently, a NAT provides:

    > - A degree of de-facto firewalling for everyone.
    > - An immunity to renumbering for enterprises.
    > - Fully automated network routing for ISPs.

    > If technologies could be introduced to tackle especially the last two,
    > I think the advantages of NATs would vanish.

Even assuming we could provide 1-3 above in some way (which I am somewhat
dubious about), I would have to say 'I don't think so' to your conclusion -
because I think your list is incomplete. The Internet as actually deployed
depends crucially on having a number of disjoint low-level naming realms -
which necessitate NAT boxes between them.

For one, my understanding of the current plan for interoperability between
IPv6 devices with an IPv6-only address, and 'the' IPv4 Internet, is the
'IPv4/IPv6 Translation' work from BEHAVE, and that's basically NAT. (There
was, a long time ago, some proposal for having such IPv6 devices with an
IPv6-only address 'share' an IPv4 address, to enable access to 'the' IPv4
Internet, but I guess it never came through.) On that alone, NATs will be
with us for decades to come.

For another, there are lots of people who have networks behind NAT boxes, for
a variety of reasons (maybe they couldn't get the address space, maybe - like
all those home wireless networks - it was just easier to do it that way). And
there is, for most of them, no economic incentive to change that, to give up
their private naming realm. (Sure, there will be a few exceptions, for whome
it does make economic sense to get rid of NAT - e.g. large ISPs for whom NAT
hacks make life too complex - but there will still be a lot left after that.

So unless you have a viable scenario in which disjoint naming realms go away,
then you do not have a viable scenario in which NATs go away.

     Noel

---

From: [email-masked] (Noel Chiappa)
Date: Fri, 8 Oct 2010 15:37:25 -0400 (EDT)

Noel