Subject: Re: US DoD and IPv6

From: [email-masked] (Noel Chiappa)
Date: Tue, 5 Oct 2010 20:16:13 -0400 (EDT)

> From: RJ Atkinson <[email-masked]>

    > It seems so incredibly unlikely that end-to-end connectivity (i.e.
    > without NAT, NAPT, or other middleboxes) is going to increase in future.

Indeed. It seems that the likelihood of IPv6 being used ubiquitously to
provide end-end IPv6-IPv6 connectivity, as originally envisioned, is fairly
small; instead, it seems we are headed for a future of various kinds of
lash-ups (e.g. the scenario you posited with content providers, or with IPv6
being used between the cable modem and some sort of CGN IPv6/IPv4 NAT, with
IPv4 on the other pieces of the path, as one large ISP has proposed).

The interesting question, of course, is whether (and if so, when) the IETF
will deign to notice this reality - or will it continue to prefer to stick
its collective fingers in its ears and keep going 'neener-neener-neener'.

	Noel

---

From: Keith Moore <[email-masked]>
Date: Tue, 5 Oct 2010 20:24:34 -0400

> its collective fingers in its ears and keep going 'neener-neener-neener'.

Do you actually have a point to make, Noel, or are you just taking pot shots at IETF again?

Keith

---

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

>  without NAT, NAPT, or other middleboxes) is going to increase in future.

Say end-to-end NAT (<draft-ohta-e2e-nat-00.txt>).

Port restricted IP by end-to-end NAT keeps the end-to-end
connectivity and effectively extend IPv4 address space by
factor of 100 or 1,000.

The point is to keep the end-to-end transparency is to let end
systems aware of and help NAT functionality.

Current loss of end-to-end connectivity by existing NAT boxes
will be restored if the boxes are replaced/upgraded to have
end-to-end NAT capability.

						Masataka Ohta

---

From: "Michel Py" <[email-masked]>
Date: Tue, 5 Oct 2010 22:10:34 -0700

>> Noel Chiappa wrote:

> Keith Moore wrote:

Look who's talking. Despite a brilliant mind and sometimes significant
contributions, you are one of the main persons behind the failure of
IPv6. The living example of the IETF ivory tower.

Has it occurred to you that, if it was not for your blind opposition to
NAT, we could be living in a world of 6to4 implemented in the ubiquitous
NAT box?

Look what you have done: not only we have more NATv4 than ever, but now
we also have NAT46, NAT64, NAT464...whatever and all of these with heavy
ALG layers to make it more palatable.

Congratulations.

Michel.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 06 Oct 2010 14:56:39 +0900

> ALG layers to make it more palatable.

FYI, with end to end NATv4, all the applications, including PORT
command of FTP, just work without any ALG layers at all.

End to end NAT does not even have TLG layers of transport
checksum recalculations, and port translations.

For the end to end transparent NAT, NAT boxes can do nothing
other than the simplest address translation and rest of the
job must be done by end systems.

						Masataka Ohta

---

From: Keith Moore <[email-masked]>
Date: Wed, 6 Oct 2010 07:52:41 -0400

> NAT, we could be living in a world of 6to4 implemented in the ubiquitous

Why do you think I proposed 6to4 in the first place?   There was no vendor interest in putting 6to4 in NAT boxes.

For that matter, I also proposed a mechanism to allow applications to better cope with NAT between v4 and v6  (and by extension between v4 and v4) by making the NATs explicitly controlled by the endpoints.  There was no interest in that either.

> ALG layers to make it more palatable.

I think you give me far more "credit" than I'm due.  

Keith

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 6 Oct 2010 11:27:41 -0400

> its collective fingers in its ears and keep going 'neener-neener-neener'.

Application designers who produce designs that rely on IP addresses being
end-to-end are going to find their work fails.

Since the one legacy protocol that has a dependency on IP address constancy
is FTP, it would seem to me to be much easier to upgrade FTP to remove the
dependency than to try to control the network.

Since FTP is layered on Telnet (no really, it is) it would seem that the
more sensible approach would be to standardize the file handling extensions
to SSH and move FTP to historic status.

At the moment we have a situation where everything layers over HTTP or HTTPS
because they provide NAT passthrough.

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

---

From: "Fleischman, Eric" <[email-masked]>
Date: Wed, 6 Oct 2010 09:47:47 -0700

Gentlemen:

The IPv6 deployment is what it is and nobody is to blame that it isn't greater or less than it is. It should not surprise anybody that IPv6 hasn't been more widely deployed to date, because, after all, I explained back in 1993 in RFC 1687 why that would happen. 

Going forward, there are many business reasons why IPv6 will increasingly become deployed and many business reasons why IPv4 use will actually grow. Thus, we can be assured that the Internet will be a mixed environment for the next many years to come. We have many existing technologies and approaches that handle such mixed environments. There is no reason to be upset -- this is the most probable result to the IPv4 address depletion problem. No surprises here.

Best wishes,

--Eric

---

From: "Michel Py" <[email-masked]>
Date: Wed, 6 Oct 2010 21:29:22 -0700

> Michel Py wrote:
>> Has it occurred to you that, if it was not for your
>> blind opposition to NAT, we could be living in a world
>> of 6to4 implemented in the ubiquitous NAT box?

> Keith Moore wrote:
> Why do you think I proposed 6to4 in the first place? There
> was no vendor interest in putting 6to4 in NAT boxes.

They got tired of systematic torpedoing of anything that looked like
NAT, walked like NAT, quacked like NAT and being told relentlessly that
their product was crap in a plastic box and decided that it was less
trouble and more profit to build a NAT box without 6to4.

>> Look what you have done: not only we have more NATv4 than ever,
>> but now we also have NAT46, NAT64, NAT464...whatever and all of
>> these with heavy ALG layers to make it more palatable.

> I think you give me far more "credit" than I'm due.  

Maybe, and I certainly deserve some "credit" myself; nevertheless some,
(rather large) amount of some flavor of NAT was unavoidable and I still
believe that it would have been more productive to accept that fact
instead of trying to get rid of any kind of any NAT altogether.

> Noel Chiappa wrote:
> in some sense the real guilty party in the IPv6 choice is the IETF
> at large, the ordinary members - for accepting what was basically
'IPv4
> with a few more bits', instead of a fundamentally revised architecture
> that would provided real benefits in the form of major new
capabilities
> (e.g. separation of location and identity), thereby giving actual
> operational incentives to drive migration.

Problem is that IPv6 is much more than IPv4 with more bits. Please note
that this is not a "I told you so" post; I would certainly have opposed
what I will suggest below.

In the end though, we would be better off now if we had gone the road
"it's all the same just pad some extra zeroes" instead of this grandiose
solve-it-all almost-perfect protocol we all dreamed of.

As of ID/LOC separation, the sad truth is that we both tried, and we
both failed. And we're not the only ones or the first ones or the last
ones to try either.

Our collective failure is that we have launched a protocol with "to be
delivered soon" advanced features that unfortunately have proved to be
impossible to deliver. Such as, {cough} PA-based multihoming.

Now, what we have on our hands is a mess with a protocol in state of
"non-deployment" that is not advanced enough to justify a large scale
deployment (especially with Moore's law still going), but WAY more
costly to deploy than a dumb "just more bits" upgrade.

Michel.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 6 Oct 2010 22:04:46 -0700

NEW NON-IETF LIST ANNOUNCEMENT

IETF Ad Hominem Discussions

This group is dedicated to the discussion of the personal flaws of  
IETF participants.
-- Airing of old grievances
-- Arguments about who gets credit for what
-- Revelation of hidden conflicts of interest / conspiracies

<http://groups.google.com/group/ietf-ad-hominem>

On Oct 6, 2010, at 9:29 PM, Michel Py wrote:

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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 07 Oct 2010 08:02:29 +0200

Yes, please, stop immediately this thread (at least the "personal" way it is
going on) or I will be forced as sergeant-at-arms to remove the participants
from the IETF mail exploder.

Regards,
Jordi

> From: "Richard L. Barnes" <[email-masked]>
> Reply-To: <[email-masked]>
> Date: Wed, 6 Oct 2010 22:04:46 -0700
> To: Michel Py <[email-masked]>
> Cc: <[email-masked]>, Keith Moore <[email-masked]>, Noel Chiappa
> <[email-masked]>
> Subject: IETF-ad-hominem (Was: Re: US DoD and IPv6)
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: "Michel Py" <[email-masked]>
Date: Wed, 6 Oct 2010 23:00:35 -0700

Fine, remove me.

-----Original Message-----
From: JORDI PALET MARTINEZ [mailto:[email-masked]] 
Sent: Wednesday, October 06, 2010 11:02 PM
To: [email-masked]; Michel Py
Cc: [email-masked]; Keith Moore; Noel Chiappa
Subject: Re: IETF-ad-hominem (Was: Re: US DoD and IPv6)

Yes, please, stop immediately this thread (at least the "personal" way
it is
going on) or I will be forced as sergeant-at-arms to remove the
participants
from the IETF mail exploder.

Regards,
Jordi

This electronic message contains information which may be privileged or
confidential. The information is intended to be for the use of the
individual(s) named above. If you are not the intended recipient be
aware that any disclosure, copying, distribution or use of the contents
of this information, including attached files, is prohibited.

---

From: "Michel Py" <[email-masked]>
Date: Wed, 6 Oct 2010 23:02:40 -0700

Keep your head in the sand. Efforts towards convergence to a post mortem
are rarely fast and rarely painless.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 07 Oct 2010 18:19:20 +0900

> what I will suggest below.

Agreed.

> both failed. And we're not the only ones or the first ones or the last

I specified and implemented ID/LOC separation and it worked.
So, I have some insight on it.

> impossible to deliver. Such as, {cough} PA-based multihoming.

For PA-based multihoming, ID/LOC is not essential. An ID and
multiple locators is just as good as multiple addresses.

W.r.t. IPv6, however, an 8B ID and 8B locators means about half
amount of storage than 16B addresses. That's all.

So, the better solution should have been IPv6 with 8B addresses.

Then, the problem for PA is that, when you say PA, you must
define what P is, as everyone want to be a P.

To me, it is obvious that there should be small number
of Ps, to which all the other entities (including small ISPs)
should be multihomed.

But, it is also obvious that my idea is not politically acceptable
to regional NICs where small ISPs have dominant voting rights.

						Masataka Ohta

---

From: Dave Cridland <[email-masked]>
Date: Thu, 07 Oct 2010 10:50:33 +0100

> Fine, remove me.

Yeah! He started it! It's so unfair. I don't even like your stupid  
mailing list anyway, so there!

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 7 Oct 2010 09:02:50 -0400

It is not an ad-hominem argument. And ad-hominem is only invalid as a form
of logical argument, it is actually legitimate when considering facts and
axioms.

Strictly speaking Ad-Hominem would be 'that idea must suck, X likes it'.

What was stated was 'your refusal to be reasonable on this issue is the
reason why IPv6 is not deployed'.

Which in this particular case happens to be the fact.

For the past fifteen years, the IPv6 deployment strategy has been based on
features. Which is a bad strategy because applications want to have as few
dependencies on the details of the underlying layers as is possible.

In particular there have been people who have argued against making NAT
transparent in case it is a little too good and delays deployment of IPv6
further.

After fifteen years the market has rejected that approach. Carrier grade NAT
has a much higher priority than IPv6 for the product managers of all the
router layer companies who send people to IETF.

On Thu, Oct 7, 2010 at 1:04 AM, Richard L. Barnes <[email-masked]> wrote:

> This group is dedicated to the discussion of the personal flaws of IETF
> participants.

---

From: Ofer Inbar <[email-masked]>
Date: Fri, 8 Oct 2010 10:25:10 -0400

> dependency than to try to control the network.

There are other protocols hiding out there.

MATIP, RFC2351 (not from the IETF, obviously), allows either endpoint
to send a session-open setting some paramaters for the session, and to
confirm the session-open from the other side.  So if both sides send
session-open, they're both supposed to ignore the session opened by
the endpoint with the lower-numbered IP.

In practice, what this seems to mean is that sometimes when you set
up new links, MATIP doesn't work, you get on the phone with the admins
at the other side, and you agree which one of you will send the
session open.  Then you configure one endpoint never to send it.

The RFC was published in 1998, though I don't know when they actually
came up with the protocol.  Its use is, I think, still increasing, as
more airline industry links are set up over TCP/IP networks.

I wouldn't have known about MATIP if I hadn't gotten a job related to
airline industry networking, and I'm sure there are other naive
protocols out there, designed by people or groups who were not that
familiar with the way of the Internet and do protocols their own ways.

[MATIP has a host of other problems that I won't mention :) ]
  -- Cos

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 07 Oct 2010 09:56:11 -0700

> This group is dedicated to the discussion of the personal flaws of IETF

Such a fertile thread you've created.  So much to play with...

If I want to say that this new list is a foolish idea and you are being 
hopelessly naive in creating it -- and thereby I am crossing into ad homimen... 
or am I -- must I do that on the new list that I disapprove of or should I do it 
here, where its formation is announced?

To the extent that there is a hint of seriousness to my post, I'll merely note 
that expecting folks to a) acknowledge that they are making an ad hominem, and 
b) choose to move to another venue is, ummm... a tad idealistic, given the 
emotions and style that tend to be present in a poster who is making ad hominem 
comments.

So I applaud your goal, but can't imagine its being achieved.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net