Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic

From: Keith Moore <[email-masked]>
Date: Sun, 3 Jul 2011 02:36:25 -0400

On Jul 3, 2011, at 2:23 AM, Ray Hunter wrote:

> IMHO Right now, we need services with native IPv6 based interfaces, with equivalent performance and equivalent features and equivalent price that we have today with IPv4. Anything that detracts from the roll out of native IPv6 based service interfaces at this time is a bad move IMVHO and hastens the day that the Internet fragments into a bunch of CGN zones, that is dominated by businesses that can afford to buy public IPv4 addresses for their servers or services, or whose business model relies on NAT traversal being difficult. I personally don't want that sort of Internet.

Right now, applications developers need to be able to write and ship code that uses IPv6 and can talk to other application instances using IPv6.   Anything that detracts from the ability of applications to use IPv6 at this time is a bad move IMHO and decreases the chance that there will ever be sufficient use of IPv6 (of any kind) to justify widespread deployment of native IPv6.

> Given that development and engineering support time is finite, I'd much rather that 6to4 was declared historic so that developers and engineers could spend more time on deployment of native IPv6 service interfaces.

I have a better suggestion: let's declare NAT historic.  That would free up lots of developers and engineers to spend time on both native v6 and better v6 transition mechanisms.  Not only would they not need to engineer new NATs, applications developers wouldn't need to engineer new workarounds for new NATs.  Everybody would win.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sun, 3 Jul 2011 03:29:21 -0400

On Jul 3, 2011, at 3:15 AM, Ray Hunter wrote:

> Keith Moore wrote:
> I'm presuming your second comment was facetious.

Mostly.   Though I do think that declaring NAT historic is absolutely as valid as declaring 6to4 historic.    Both 6to4 and NAT are things that are useful in some cases and cause harm in others.  Except that 6to4 doesn't actually cause harm except in conjunction with other dubious practices (bogus anycast route advertisements, protocol 41 filtering, use public IPv4 addresses behind LSN) which are outside of 6to4's scope, whereas NAT inherently causes harm.

But it wan't a serious suggestion, just an analogy.

> I'm also presuming from your first comment that you will thus oppose the proposal to turn off 6to4 by default.
> 
> Am I correct?

I've already said on several occasions that I agree that 6to4 should be off by default.   It's mostly the Historic label that I have the problem with.   (I have other objections to the document also, but those are just places where I think the wording is misleading.  The label is the big thing.)

Keith

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 3 Jul 2011 05:32:23 -0700

On Jul 3, 2011 12:29 AM, "Keith Moore" <[email-masked]> wrote:
> >>> IMHO Right now, we need services with native IPv6 based interfaces,
with equivalent performance and equivalent features and equivalent price
that we have today with IPv4. Anything that detracts from the roll out of
native IPv6 based service interfaces at this time is a bad move IMVHO and
hastens the day that the Internet fragments into a bunch of CGN zones, that
is dominated by businesses that can afford to buy public IPv4 addresses for
their servers or services, or whose business model relies on NAT traversal
being difficult. I personally don't want that sort of Internet.
> >>>
> >>
> >> Right now, applications developers need to be able to write and ship
code that uses IPv6 and can talk to other application instances using IPv6.
  Anything that detracts from the ability of applications to use IPv6 at
this time is a bad move IMHO and decreases the chance that there will ever
be sufficient use of IPv6 (of any kind) to justify widespread deployment of
native IPv6.
> >>
> >>
> >>> Given that development and engineering support time is finite, I'd
much rather that 6to4 was declared historic so that developers and engineers
could spend more time on deployment of native IPv6 service interfaces.
> >>>
> >>
> >> I have a better suggestion: let's declare NAT historic.  That would
free up lots of developers and engineers to spend time on both native v6 and
better v6 transition mechanisms.  Not only would they not need to engineer
new NATs, applications developers wouldn't need to engineer new workarounds
for new NATs.  Everybody would win.
> Mostly.   Though I do think that declaring NAT historic is absolutely as
valid as declaring 6to4 historic.    Both 6to4 and NAT are things that are
useful in some cases and cause harm in others.  Except that 6to4 doesn't
actually cause harm except in conjunction with other dubious practices
(bogus anycast route advertisements, protocol 41 filtering, use public IPv4
addresses behind LSN) which are outside of 6to4's scope, whereas NAT
inherently causes harm.

Right. Because you are not accountable for growing the internet or customer
experience. The people that say kill 6to4 are. I hope that is clear to iesg.
Please look closely at the motives.

Cb

> I've already said on several occasions that I agree that 6to4 should be
off by default.   It's mostly the Historic label that I have the problem
with.   (I have other objections to the document also, but those are just
places where I think the wording is misleading.  The label is the big
thing.)
>
> Keith
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Keith Moore <[email-masked]>
Date: Sun, 3 Jul 2011 09:14:14 -0400

On Jul 3, 2011, at 8:32 AM, Cameron Byrne wrote:
> Right. Because you are not accountable for growing the internet or customer experience. The people that say kill 6to4 are. I hope that is clear to iesg. Please look closely at the motives.
> 

Note that the ONLY substantive thing we're arguing about here is the Historic label.    I don't see any significant disagreement about the technical details.

Keith

---

From: Ray Hunter <[email-masked]>
Date: Sun, 03 Jul 2011 08:23:07 +0200

>
> Subject:
> Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
> From:
> Keith Moore <[email-masked]>
> Date:
> Sat, 2 Jul 2011 23:10:47 -0400
>
> To:
> Cameron Byrne <[email-masked]>
> CC:
> "[email-masked]" <[email-masked]>, IETF Discussion <[email-masked]>
>
> Precedence:
> list
> MIME-Version:
> 1.0 (Apple Message framework v1084)
> References:
> <[email-masked]> 
> <CAKD1Yr2Smvm0RY5iV2y06wD=[email-masked]> 
> <[email-masked]>
> In-Reply-To:
> <[email-masked]>
> Message-ID:
> <[email-masked]>
> Content-Type:
> multipart/alternative; boundary=Apple-Mail-111-642965515
> Message:
> 2
>
>
>
> I find myself wondering what you mean by REAL IPv6.  For me, REAL IPv6 
> is code that uses the IPv6 programming model, 128 bit addresses, 
> end-to-end transparency, no NATs.  6to4 certainly qualifies.
>
> Keith
Many people have many more requirements. For example, an SLA for 
availability and latency, low support costs, firewall security, DSCP 
quality of service, ability to log end point communications, intrusion 
detection, WAN acceleration, a deployment model that does not rely on 
allocating even more IPv4 addresses (that many don't have or won't have) 
or the good nature of other providers to provide a working relay .......

6to4 fails to meet many of those requirements. Granted, it isn't the 
only transition mechanism that fails to do so.

IMHO Right now, we need services with native IPv6 based interfaces, with 
equivalent performance and equivalent features and equivalent price that 
we have today with IPv4. Anything that detracts from the roll out of 
native IPv6 based service interfaces at this time is a bad move IMVHO 
and hastens the day that the Internet fragments into a bunch of CGN 
zones, that is dominated by businesses that can afford to buy public 
IPv4 addresses for their servers or services, or whose business model 
relies on NAT traversal being difficult. I personally don't want that 
sort of Internet.

Given that development and engineering support time is finite, I'd much 
rather that 6to4 was declared historic so that developers and engineers 
could spend more time on deployment of native IPv6 service interfaces.

Having said all that, 6to4 has also caused me issues with traffic 
predictability, and cost significant engineering time. Turning 6to4 off 
by default would not be the ideal solution in my view, but it should 
address many if not all of my own particular issues. If that's all 
that's on offer, I'll take it.

regards,
RayH

---

From: Ray Hunter <[email-masked]>
Date: Sun, 03 Jul 2011 09:15:59 +0200

I'm also presuming from your first comment that you will thus oppose the 
proposal to turn off 6to4 by default.

Am I correct?

regards
RayH,