Subject: Re: US DoD and IPv6

From: [email-masked] (Noel Chiappa)
Date: Tue, 12 Oct 2010 16:08:22 -0400 (EDT)

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

    > On 10/10/2010 2:51 PM, Steve Crocker wrote:

    >> A compatible solution would have been better

    > The community got ambitious

It's interesting that you should say this, because I've always been critical
of IPv6 because, IMO, it wasn't _ambitious enough_ - in fact, I think that
was a big factor in something you raised in a later message:

    >>> Quite simply, we did not pay attention to larger issues such as market
    >>> incentives and adoption barriers.

The lack of market incentives is, IMO, intimately connected to the lack of new
functionality - functionality which would have meant a more ambitious design.

However, on thinking about this, I think there is a way to reconcile your
'too ambitious' and my 'not ambitious enough' - and it's a way that provides
what I think is an important insight.

I think you're right in a way about the 'too ambitious', in the sense that
the plan supposed not an incremental, interoperable evolvement of IPv4 (such
as the ones you mentioned with "all this transition stuff is fine, but when
it's done, what we'll be left with will be ugly"), but spent most of its
technical energy thinking about a 'clean slate' design; in a way, one could
say it was too ambitious in the 'engineering details', as it were.

At the same time, I think I'm right in a way about the 'not ambitious
enough', in the sense that the plan supposed pretty much the same
architecture as IPv4; in short, one could say it was not ambitious enough in
the 'architectural big picture'.

So, if people will forgive me, I think one can play on one of Jon's favourite
quotations, and say that when contemplating the evolution of a
very-large-scale communication network, one should 'be conservative in ones
engineering details, and liberal in one's architectural vision'.

The 'conservative in the engineering details' means that interoperability and
evolution will be maximized, which will minimize adoption barriers; and the
'liberal in architectural vision' will maximize incentives - thereby giving
one the best possible change of overcoming the adoption barriers which have so
hampered deployment of the stuff currently being discussed.

    > smacked of the overreaching that is often called second system syndrome

    > From: Marshall Eubanks <[email-masked]>

    > Was it second system syndrome

I think it's useful to remember that if one looks at the original source of
the 'second system syndrome', "Mythical Man Month" by Brooks, it ends the
discussion of 'second system syndrome' with the following observation:

    "The second-system effect has another manifestation somewhat different
    from pure functional embellishment. That is a tendency to refine
    techniques whose very existence has been made obsolete by changes in
    basic system assumptions."

I will leave it to readers to gauge if, and how much, this applies to our
current situation.

	Noel

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 13 Oct 2010 06:53:31 +0900

> functionality - functionality which would have meant a more ambitious design.

IPv6 and Neighbor Discovery were designed so ambitiously that they
have so much new functionality.

The problem is that the added functionality does not function as
expected, is not required by the market and is rather harmful
than useless.

Examples are 16B addresses, unlimited optional headers, path MTU
discovery, support for NBMA (ATM) networks, stateless auto
configuration and flow.

So, how can you say "more ambitious"?

> but spent most of its
> technical energy thinking about a 'clean slate' design; in a
> way, one could say it was too ambitious in the 'engineering
> details', as it were.

Using a clean slate is of no help when you write much more than
what was already written on a scribbled slate.

						Masataka Ohta

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 13 Oct 2010 00:20:46 -0400

On 10/12/2010 4:08 PM, Noel Chiappa wrote:
> of IPv6 because, IMO, it wasn't _ambitious enough_ -

I didn't say creative.  I didn't say it targeted a new paradigm.  I merely meant
that it tried to attack more than the problem at hand.  And I didn't say it did
that well.

By the same token, one can and I believe should note that those insisting that a
new paradigm be used were given a 15 year window of opportunity and didn't seem 
to pursue it very much...

> The lack of market incentives is, IMO, intimately connected to the lack of
> new functionality - functionality which would have meant a more ambitious
> design.

yup.  however note that companies successfully market products that have no 
interesting new features...

> say it was too ambitious in the 'engineering details', as it were.

ack.

> the 'architectural big picture'.

there was no mandate to create a new architecture.  to adopt a new architecture 
would have required making an extremely compelling case, with more detail and 
demonstration.  and although the formal choice was made early, the actual 
failure to deliver 'product' provided a 15-year window, as I said.

Please note that OSI also was committed to early and also failed to deliver... 
and was replaced by an alternative that /did/ deliver.  So we have a nice 
example that this later adoption of a better alternative was feasible.

> So, if people will forgive me, I think one can play on one of Jon's
> favourite quotations, and say that when contemplating the evolution of a

   ... but not necessarily at the same time.

incremental evolution is a fine and valid and efficient path.  changing 
architectural paradigms is massively traumatic and, therefore, needs a more 
compelling incentive.

> The 'conservative in the engineering details' means that interoperability
> and evolution will be maximized, which will minimize adoption barriers; and
> the 'liberal in architectural vision' will maximize incentives - thereby
> giving one the best possible change of overcoming the adoption barriers which
> have so hampered deployment of the stuff currently being discussed.

sounds about right to me.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 12 Oct 2010 19:46:01 -0400

The original idea seems to have been that IPSEC would be a big enough
incentive to upgrade.

Since then IPSEC has been separated out and we have discovered that packet
layer security is not nearly so useful as transport layer.

Back in PARC there was a think called error 33: building research on
research. Tying deployment of necessary functionality to unrelated
infrastructure projects has not had a good success record.

On Tue, Oct 12, 2010 at 4:08 PM, Noel Chiappa <[email-masked]>wrote:

> new
> favourite
> and
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Oct 2010 09:27:10 +1300

> The original idea seems to have been that IPSEC would be a big enough

I've been keeping out of this conversation because I have other things to do,
like working on effective technologies for v4/v6 coexistence, but I have
to protest at this version of the "IPv6 is more secure" myth. I don't
think anybody ever advanced this as a serious technical incentive.

What was always pointed out is that IPv6 use of IPsec doesn't have to
deal with NAT traversal, which was an issue for IPv4 use of IPsec,
until RFC 3948 came along in 2005. Since then, even the weak form of
the "more secure" myth has been indefensible.

I am of course discounting bogus marketing arguments.

     Brian

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 13 Oct 2010 17:35:50 -0400

On 10/13/2010 4:27 PM, Brian E Carpenter wrote:
>   I have

I heard the most august Howard Schmidt make a simple and direct claim that it 
was, a few years back.

I asked him about it privately and got an answer that mostly was of the form 
"it's a new chance to look at security issues".  This, of course, had nothing to 
do with the sort of assertion he had made.

v6 has regularly been sold with promises for all sorts of things it was not 
designed to deliver.  While it's never possible to ensure that this sort of 
thing never happens, the v6 effort really did not work very hard at producing 
and delivering a clear message of the problems it /would/ solve.

d/
-- 

   Dave Crocker

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 14 Oct 2010 09:43:19 +0900

> deal with NAT traversal, which was an issue for IPv4 use of IPsec,

It should be noted that IPsec, including AH, works transparently
over port restricted IP, including end to end NAT, if a 4B SPI
is used as a 2B source and a 2B destination port numbers.

> the "more secure" myth has been indefensible.

IP over TCP is a more robust kludge for legacy NAT.

						Masataka Ohta

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 13 Oct 2010 21:20:21 -0400

I said that it seems to have been the original marketing pitch, not that it
was a good one or that it was going to add security.

That was when almost all of us (myself included) were going through our
'cryptography makes everything secure phase'.