Subject: Re: existing (and questionable) application designs [was Re: US DoD and IPv6]

From: [email-masked] (Noel Chiappa)
Date: Thu, 7 Oct 2010 10:20:34 -0400 (EDT)

> From: Brian E Carpenter <[email-masked]>

    > The problem is that the creation of disjoint addressing realms (due to
    > NAT and to IPv4/IPv6 coexistence) has made distributed application
    > design almost impossible without kludges.

See, this is the kind of thing I was talking about in my early post in the
recent incarnation of this thread. Complaining about the existence of
disjoint naming realms, and how it has complicated our lives, is like a
rocket scientist complaining about gravity, and how hard it makes their job.
(OK, it's not quite a perfect analogy, since gravity is fundamental, but I
think my point is clear.)

They were inevitable, end of story. This is the architectural reality we live
in, and we need to accept that, and fully align IETF work around that reality
- and not act like it's a red-headed step-child that will sit in a corner and
be quiet if we don't deign to pay attention to it.

Yes, it does make our lives as engineers a lot harder. Trying to do
fundamental architectural upgrade an enormous, in-service communication
system is hard too - much, much harder than a clean sheet design, and filled
with all sorts of kludges on the edges where you have to interface to
existing stuff. However, if you just accept that that's what you have to do,
and get on with it, you can make non-trivial progress.

	Noel

---

From: Keith Moore <[email-masked]>
Date: Thu, 7 Oct 2010 10:58:30 -0400

On Oct 7, 2010, at 10:20 AM, Noel Chiappa wrote:

> They were inevitable, end of story.

No, they were not inevitable, at least not in the long term.  Two cases:

1.  There were IPng proposals that would have made IPng an extension of IPv4 space, and allowed (at least in the interim) all IPng traffic to be tunneled over IPv4 networks.   This understandably made routing people and network operators uneasy as nobody wanted to live with the Class C swamp forever.  But in hindsight there were probably other ways of dealing with that problem.  And being able to leverage the existing IPv4 network in a general way would have made IPng easier to deploy.  (Admittedly, what looked deployable in the early 1990s when these tradeoffs were being discussed is very different from what looks deployable now.  In 1991, say, it was much easier to imagine the whole Internet migrating to a new protocol than it was even a couple of years later.)

2. In the late 1990s when it became apparent that NATs were causing problems, IETF had an opportunity to put a stake in the ground.  It could have tried to find a way to integrate NATs into an explicit Internet architecture; it could have explained why NATs presented difficult problems for which there were no good solutions; it could have tried to define NAT in such a way as to permit a more graceful migration to IPv6.   It failed at all three of these, not because of insurmountable technical difficulties, but because (a) too many people were afraid of alienating NAT vendors, and (b) IAB, the only part of IETF that had any responsibility for architectural direction, had been stripped of its power in the wake of Kobe.  

In fact, as we should realize by now, IAB's concerns that dictated the Kobe decision were extremely well founded, even if a lot of us (myself included) didn't like the specific choice they made.  But as it turned out, we didn't really have enough time to use our normal "rough consensus" process to specify IPng.  

All of this is water that has already flowed under the bridge, of course.  But I think there is at least one thing that we need to learn from this going forward, and that is that there really is a need for a small group of wise and widely-trusted people to be able to set architectural direction for the internet.  And occasionally, they're going to make unpopular decisions.  But those are the sort of issues for which a rough consensus process demonstrably does not work.

Keith

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 7 Oct 2010 13:40:04 -0400

All true, but based on the information available at the time, I am not sure
how a different outcome would have been arrived at.

Having a group to make unpopular but right decisions always seems a great
idea in hindsight. But there is a real practical difficulty distinguishing
such groups form similar groups whose ideas are both unpopular and wrong.

The reason the IAB has no authority is that the selection mechanism is
designed to ensure that it has no accountability. No accountability means no
authority.

What you seem to be saying is that the IETF should have made deployment a
much higher priority in the design of IPv6. Which is what I have been saying
for years.

I treat deployment as an engineering problem. I have been constructing
models and running simulations to test various approaches to deployment
since 1992.

I can construct a plausible deployment model for IPv6 based on NAT boxes.
But I can't see a plausible model which does not involve NAT44, NAT46 and
NAT66 during the transition period and since I am anticipating that lasting
around thirty years, I can't see much point in modeling what comes after.

On Thu, Oct 7, 2010 at 10:58 AM, Keith Moore <[email-masked]>wrote:

> 1.  There were IPng proposals that would have made IPng an extension of
> IPv4 space, and allowed (at least in the interim) all IPng traffic to be
> tunneled over IPv4 networks.   This understandably made routing people and
> network operators uneasy as nobody wanted to live with the Class C swamp
> forever.  But in hindsight there were probably other ways of dealing with
> that problem.  And being able to leverage the existing IPv4 network in a
> general way would have made IPng easier to deploy.  (Admittedly, what looked
> deployable in the early 1990s when these tradeoffs were being discussed is
> very different from what looks deployable now.  In 1991, say, it was much
> easier to imagine the whole Internet migrating to a new protocol than it was
> even a couple of years later.)
>
> 2. In the late 1990s when it became apparent that NATs were causing
> problems, IETF had an opportunity to put a stake in the ground.  It could
> have tried to find a way to integrate NATs into an explicit Internet
> architecture; it could have explained why NATs presented difficult problems
> for which there were no good solutions; it could have tried to define NAT in
> such a way as to permit a more graceful migration to IPv6.   It failed at
> all three of these, not because of insurmountable technical difficulties,
> but because (a) too many people were afraid of alienating NAT vendors, and
> (b) IAB, the only part of IETF that had any responsibility for architectural
> direction, had been stripped of its power in the wake of Kobe.
>
> In fact, as we should realize by now, IAB's concerns that dictated the Kobe
> decision were extremely well founded, even if a lot of us (myself included)
> didn't like the specific choice they made.  But as it turned out, we didn't
> really have enough time to use our normal "rough consensus" process to
> specify IPng.
>
> All of this is water that has already flowed under the bridge, of course.
>  But I think there is at least one thing that we need to learn from this
> going forward, and that is that there really is a need for a small group of
> wise and widely-trusted people to be able to set architectural direction for
> the internet.  And occasionally, they're going to make unpopular decisions.
>  But those are the sort of issues for which a rough consensus process
> demonstrably does not work.
>
> Keith
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

-- 
Website: http://hallambaker.com/