Subject: draft-ietf-v6ops-6to4-to-historic (yet again)

From: Ronald Bonica <[email-masked]>
Date: Mon, 25 Jul 2011 10:30:46 -0400

Folks,

After some discussion, the IESG is attempting to determine whether there is IETF consensus to do the following:

- add a new section to draft-ietf-v6ops-6to4-to-historic
- publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL

draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and convert their status to HISTORIC. It will also contain a new section describing what it means for RFCs 3056 and 3068 to be classified as HISTORIC. The new section will say that:

- 6-to-4 should not be configured by default on any implementation (hosts, cpe routers, other)
- vendors will decide whether/when 6-to-4 will be removed from implementations. Likewise, operators will decide whether/when 6-to-4 relays will be removed from their networks. The status of RFCs 3056 and 3068 should not be interpreted as a recommendation to remove 6-to-4 at any particular time.

draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it clarifies the meaning of "HISTORIC" in this particular case, it does not set a precedent for any future case.

Please post your views on this course of action by August 8, 2011.

                                                                   Ron Bonica
                                                                   <speaking as OPS Area AD>

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Jul 2011 13:14:42 -0400

I remain strongly opposed to reclassifying 6to4 as Historic unless/until a better alternative appears.  Putting an explanation inside an informational document doesn't change that opposition.

I also continue to believe that the -historic draft has too many misstatements and misleading statements in it, that the entire motivation for the draft is seriously flawed, and that it should not be published in anything like its current form.

But I agree that 6to4 should be off by default, mostly because there's no good off-the-shelf way to have 6to4 automatically disabled when a host or router connects to a network that is using NAT but not using RFC 1918 addresses.

Keith

On Jul 25, 2011, at 10:30 AM, Ronald Bonica wrote:

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 25 Jul 2011 14:05:33 -0400

>>>>> "Keith" == Keith Moore <[email-masked]> writes:
    Keith> I remain strongly opposed to reclassifying 6to4 as Historic
    Keith> unless/until a better alternative appears.  Putting an
    Keith> explanation inside an informational document doesn't change
    Keith> that opposition.

+1
I note that multicast basically died when the mbone6 got decommissioned
too early.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Ole Troan <[email-masked]>
Date: Mon, 25 Jul 2011 14:17:14 -0400

I'm in favor of the proposed action and the clarification of historic, suggested in the new section.
(I could be in _strong_ favour to nullify Keith's 'vote', although I hope we're not counting. ;-)), .

cheers,
Ole

---

From: "Michel Py" <[email-masked]>
Date: Mon, 25 Jul 2011 11:23:26 -0700

> Ronald Bonica wrote:
> After some discussion, the IESG is attempting to determine whether
> there is IETF consensus to do the following:

Opposed. I will pass on details, as I don't think I have any wording to
contribute that has not already been discussed and re-discussed.

Michel.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Jul 2011 09:49:32 +1200

>  Likewise, operators will decide whether/when 6-to-4 relays will be removed from their networks.

This is, of course, an undeniable statement of fact (as it is for any other feature
of the Internet). However, it needs to be made clear that doing so *prematurely*
would penalise existing successful users of those relays, and therefore it should
only be done when there is no successful traffic through them. Which is when any
operator would remove them anyway.

Therefore, I don't see much value in this statement, and possible harm to users.
The ways to avoid such harm as far as possible are already in the RFC Editor
queue.

Regards
   Brian Carpenter

---

From: John Leslie <[email-masked]>
Date: Mon, 25 Jul 2011 18:54:16 -0400

> - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL

   Clearly, this is an honest effort to make 6to4-to-historic closer to
where you think a consensus might be. I do appreciate the attempt...

   ... but it feels like wandering in the weeds. :^(

   We are suffering from many differing views of what "IETF consensus"
is. IMHO, any useful definition includes that anyone who disagrees with
the "consensus" statement agrees to shut up. They may shut up almost
immediately; they may shut up after some painful appeals process; or
worst, they may only pretend to shut up and keep bringing the issue
to mind again. This last, IMHO, doesn't deserve the name "consensus".

> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and
> convert their status to HISTORIC. It will also contain a new section
> describing what it means for RFCs 3056 and 3068 to be classified as
> HISTORIC. The new section will say that:
> 
> - vendors will decide whether/when 6-to-4 will be removed from
>   implementations. Likewise, operators will decide whether/when
>   6-to-4 relays will be removed from their networks. The status of
>   RFCs 3056 and 3068 should not be interpreted as a recommendation
>   to remove 6-to-4 at any particular time.

   That's a funny definition of "historic"...
> 
> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it
> clarifies the meaning of "HISTORIC" in this particular case, it does
> not set a precedent for any future case.

   This _is_ reminiscent of what courts do when faced with a bad law.
But courts _don't_ have the option to not enact the law in the first
place. It _is_ for them the least-worst option.

> Please post your views on this course of action by August 8, 2011.

   Speaking for myself, this proposal accomplishes nothing useful.

   I actually have no particularly strong opinion on whether RFCs
3056 and 3068 deserve to be labeled "historic" at this time. I expect
they will deserve that label within a few years; but the label feels
"optimistic" at this time.

   What I _do_ have a strong opinion on is claiming in a published
RFC that we have IETF consensus to re-classify them. I do not believe
we have such consensus. I do not believe the IESG has followed a process
reasonably aimed at judging such consensus. I don't believe the IESG
even has consensus among themselves -- though if that were what the
boilerplate would claim, I wouldn't interfere.

   At some point, we need to be willing to say, "there is no consensus
at this time," and move on.

   I absolutely do not believe that reclassifying the two RFCs as
"historic" will accomplish what the proponents claim. (Neither do I
believe it would cause world-shattering harm.)

   As a general rule, I think reclassification of _anything_ to
"historic" shouldn't gate on IETF consensus -- it's just too hard.
Instead, I'd recommend some group like the IAB make the call, with
no claim to represent "consensus" of a body so large as the IETF.

   I am probably willing to shut up in any case; but I'd be a whole
lot happier if re-classification were an IAB decision. Barring that,
perhaps the RFC calling for re-classification could follow some path
which doesn't require boilerplate which claims to represent "IETF
Consensus"

   Or, the IESG could just let this document die.

--
John Leslie <[email-masked]>

---

From: Martin Rex <[email-masked]>
Date: Tue, 26 Jul 2011 02:40:10 +0200 (MEST)

Ronald Bonica wrote:
> describing what it means for RFCs 3056 and 3068 to be classified
> as HISTORIC.

I'm strongly opposed.  Discussion is in the archives.

-Martin

---

From: Christian Huitema <[email-masked]>
Date: Tue, 26 Jul 2011 01:01:57 +0000

> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and convert their status to HISTORIC. It will also contain > a new section describing what it means for RFCs 3056 and 3068 to be classified as HISTORIC. The new section will say that:

I do not think this is a good idea, and I am certainly not part of the "consensus."

-- Christian Huitema

---

From: Mark Andrews <[email-masked]>
Date: Tue, 26 Jul 2011 11:09:27 +1000

In message <[email-masked]>, Christian Huitema writes
:
> > draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and convert their status to HISTORIC. It will also contain >
>  a new section describing what it means for RFCs 3056 and 3068 to be classified as HISTORIC. The new section will say that:
> 

Seconded.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 25 Jul 2011 18:12:57 -0700

I approve of this approach.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Jul 2011 15:08:42 +1200

To be clear, I'd like to see exact proposed text before expressing
support for the proposal. The trick is to get 6to4 disabled by default
at the user end, without disabling it for users who are getting good
service from it.

Regards
   Brian

---

From: "Michel Py" <[email-masked]>
Date: Mon, 25 Jul 2011 20:25:53 -0700

Brian,

> Brian E Carpenter wrote:
> To be clear, I'd like to see exact proposed text before
> expressing support for the proposal. The trick is to get
> 6to4 disabled by default at the user end, without disabling
> it for users who are getting good service from it.

Although I commend Ron from trying "something else", I think this
particular approach is doomed to fail. Maybe I'm reading the list wrong,
but I think the sticky point here is the "historic" thing, and nothing
short of removing that part will significantly change the mindset of
people who oppose it.

Have you considered a newer revision of the 6-to-4 RFCs that would
obsolete the current ones and add that 6-to-4 should be disabled by
default? That could reach consensus.

Michel.

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 26 Jul 2011 07:16:11 +0300

Hello,

I am not an expert in the questions of 6to4, but unless there are strong 
arguments claiming that this technology is not used any more, 
reclassification isn't appropriate.  Discouraging implementation/use of 
the protocol is not a purpose of Historic, it is to mark what already 
no-one uses.  It is only possible to determine when the obvious absence 
of previous and current interest in the technology is determined by the 
community, such as eg. SiFTP, RFC 913.  I don't see such community's 
vision on 6to4, and therefore the document may not progress further 
unless strong community consensus is built.

Mykyta Yevstifeyev

---

From: Roger Jørgensen <[email-masked]>
Date: Tue, 26 Jul 2011 09:53:47 +0200

> Please post your views on this course of action by August 8, 2011.

Supported.
Guess there are so many against for whatever reason so the consensus
part will be hard.
The archive have probably all of the arguments.

But whatever happen with this one, can we please move on and focus on
the one and only important thing, native IPv6. All the other are work
around.

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Tue, 26 Jul 2011 11:43:08 +0200

In your letter dated Mon, 25 Jul 2011 20:25:53 -0700 you wrote:
>Maybe I'm reading the list wrong,

Hmm, I never bothered to really study RFC-2026. But now I found this:

[Section 6.2:]
"When a standards-track specification has not reached the Internet
"Standard level but has remained at the same maturity level for
"twenty-four (24) months, and every twelve (12) months thereafter
"until the status is changed, the IESG shall review the viability of
"the standardization effort responsible for that specification and the
"usefulness of the technology. Following each such review, the IESG
"shall approve termination or continuation of the development effort,
"at the same time the IESG shall decide to maintain the specification
"at the same maturity level or to move it to Historic status.  This
"decision shall be communicated to the IETF by electronic mail to the
"IETF Announce mailing list to allow the Internet community an
"opportunity to comment. This provision is not intended to threaten a
"legitimate and active Working Group effort, but rather to provide an
"administrative mechanism for terminating a moribund effort.

I think it is safe to say that 6to4 is a standard track protocol that is
going nowhere. So why can't the IESG just decide to move 6to4 to historic?

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 26 Jul 2011 09:47:28 -0400

Brian,

Does the following text work for you?

                         Ron

N. Meaning of HISTORIC

For the purposes of this document, the term HISTORIC means:

- 6-to-4 should not be configured by default on any implementation (host, cpe router, other)

- Vendors will decide which future versions of their products will support 6-to-4. It is assumed that vendors will continue to support 6-to-4 until a) they are no longer economically incented to do so and b) they are economically incented to remove unused features from their products.

- Operators will decide when to decommission 6-to-4 relays, if ever. It is assumed that operators will continue to operate 6-to-4 relays as long as they are economically incented to do so. When 6-to-4 traffic levels reach zero, operators will probably begin to consider decommissioning.

The status of RFCs 3056 and 3068 should not be interpreted as a recommendation to remove 6-to-4 at any particular time.

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Monday, July 25, 2011 11:09 PM
> To: Ronald Bonica
> Cc: [email-masked]
> Subject: Re: draft-ietf-v6ops-6to4-to-historic (yet again)
> 
> >> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068
> and convert their status to HISTORIC. It will also contain a new
> section describing what it means for RFCs 3056 and 3068 to be
> classified as HISTORIC. The new section will say that:
> >>
> implementations. Likewise, operators will decide whether/when 6-to-4
> relays will be removed from their networks. The status of RFCs 3056 and
> 3068 should not be interpreted as a recommendation to remove 6-to-4 at
> any particular time.
> >>
> >>

---

From: Tim Chown <[email-masked]>
Date: Tue, 26 Jul 2011 15:14:56 +0100

> Please post your views on this course of action by August 8, 2011.

Some observations.

Our own users made use of 6to4 maybe 8+ years ago, and at the time it was handy to have.  Today though we're not aware of any of our users running 6to4 intentionally. We have IPv6 native on site, and anyone who wants home IPv6 connectivity either goes to an ISP that provides it, e.g. A&A in the UK, or they use a tunnel broker.  Brokers have the additional benefit of working through NATs and with dynamic IPv4 endpoints.

Our site sees about 1-2% of all inbound traffic being IPv6, and of that less than 1% is 6to4, and this is only likely to fall further with rfc3484-bis. What 6to4 we do see is probably reasonably robust in that our return path uses the JANET-provided 6to4 relay.  

Most operating systems either already, or before long will, support rfc3484-bis, which means hosts should use IPv4 in preference to 6to4 where both are available.  To choose to use 6to4, the user would need to consciously change their 3484 policy table, assuming their OS supports that (Linux and Windows do, MacOS X Lion appears not to).

Geoff Huston has presented data at IETF80 showing 6to4 brokenness and performance. We now have 'Happy Eyeballs Lite' implemented in Chrome and (I believe, not tested it yet) Firefox, which means the browser can adapt to broken IPv6, whether caused by 6to4 or other factors.

The 6to4-advisory draft suggests off-by-default, which I agree with, and use of relays to improve user experience. The problem is we can't expect every site/ISP to run a relay (or multi-address with 6to4) so there will inevitably always be problems with the 3068 mode of 6to4.

We measured rogue RAs over a two year period on our wireless network.  About 60% of the time at least one host was emitting a rogue 6to4-based RA. While these were mitigated by ramond, it would be good to see vendors fix this; it's not just MS ICS.  Happy Eyeballs is a mitigation for such rogue RAs also.

So in summary, in practice 3484-bis and the 6to4-advisory off-by-default will further reduce what little use there is of 6to4 now, and happy eyeballs will mitigate any remaining instances of its use that are bad. So whether 6to4 is tagged Historic or not, it should be causing significantly less harm.  

Tim

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 26 Jul 2011 10:48:55 -0400

I support this proposal, for the following reasons:

1. Google's public IPv6 adoption data [1] shows that from the perspective of
a website, 6to4 is a tiny and decreasing percentage of IPv6 clients.
2. Geoff Huston's data, presented at v6ops in Prague, shows that 6to4
failure rate when connecting to dual-stack destinations is approximately
20%.
3. Large website operators such as Google, Yahoo, and Facebook have data
that show that 6to4 is an important reason for a large percentage of
dual-stack brokenness, and that dual-stack brokenness is the main reason why
their websites do not have IPv6 records today. Lack of IPv6 content is one
of the reasons most often cited by access networks when explaining the lack
of IPv6 deployment to end users.
4. A number of home gateway manufacturers are still coming out with new
devices that support 6to4 and even enable it by default when IPv6 is
enabled. Declaring 6to4 it to be historic would help ensure that those
manufacturers disable 6to4 in future products.
5. The advent of large-scale NAT will decrease the applicability of 6to4.
6. The advent of ISPs assigning bogon address space to users will
substantially
7. For those who want to do application development using IPv6, there are
alternatives to 6to4, such as manually configured tunnels. These are readily
available, work behind NATs, and in many cases offer lower latency and
higher reliability.

[1] http://www.google.com/intl/en/ipv6/statistics/

On Tue, Jul 26, 2011 at 09:47, Ronald Bonica <[email-masked]> wrote:

> - Vendors will decide which future versions of their products will support
> 6-to-4. It is assumed that vendors will continue to support 6-to-4 until a)
> they are no longer economically incented to do so and b) they are
> economically incented to remove unused features from their products.
>
> - Operators will decide when to decommission 6-to-4 relays, if ever. It is
> assumed that operators will continue to operate 6-to-4 relays as long as
> they are economically incented to do so. When 6-to-4 traffic levels reach
> zero, operators will probably begin to consider decommissioning.
>
> The status of RFCs 3056 and 3068 should not be interpreted as a
> recommendation to remove 6-to-4 at any particular time.
>
>

---

From: Tim Chown <[email-masked]>
Date: Tue, 26 Jul 2011 16:11:38 +0100

> So in summary, in practice 3484-bis and the 6to4-advisory off-by-default will further reduce what little use there is of 6to4 now, and happy eyeballs will mitigate any remaining instances of its us…

To clarify, I am in favour.

Tim

---

From: Geoff Huston <[email-masked]>
Date: Wed, 27 Jul 2011 01:14:16 +1000

I'm in favor of the proposed action and the clarification of HISTORIC as proposed in the new section.

Geoff

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 26 Jul 2011 17:37:07 +0200

I jump in the midle of discussion and lazy to dissect emails:

Is there a replacement for historic 6to4?  What should I now install in 
the lab, without interaction to some admin or web page of some core server?

Thanks,

Alex

---

From: "t.petch" <[email-masked]>
Date: Tue, 26 Jul 2011 20:35:47 +0200

It seems strange that this e-mail is not copied to the v6ops list.

I would have expected this first to have been hammered out on the v6ops list
and, if and only if consensus was reached there, the new text be then brought to
the
IETF list.

I realise that, as you spell out, you are seeking IETF consensus but what is
that if the
WG is dead set against it?

Tom Petch

----- Original Message -----
From: "Ronald Bonica" <[email-masked]>
To: <[email-masked]>
Sent: Monday, July 25, 2011 4:30 PM

> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and convert
their status to HISTORIC. It will also contain a new section describing what it
means for RFCs 3056 and 3068 to be classified as HISTORIC. The new section will
> - vendors will decide whether/when 6-to-4 will be removed from
implementations. Likewise, operators will decide whether/when 6-to-4 relays will
be removed from their networks. The status of RFCs 3056 and 3068 should not be
interpreted as a recommendation to remove 6-to-4 at any particular time.
>
>
> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it clarifies
the meaning of "HISTORIC" in this particular case, it does not set a precedent
for any future case.
>                                                                    <speaking
as OPS Area AD>

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 26 Jul 2011 15:51:40 -0400

> WG is dead set against it?

The working group adopted the document without the statement. the IESG would presumably provide instruction as to what to do next with the draft were they to conclude that the compromise was considered acceptable by the community.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 26 Jul 2011 22:04:30 +0200 (CEST)

On Tue, 26 Jul 2011, t.petch wrote:

> I realise that, as you spell out, you are seeking IETF consensus but 
> what is that if the WG is dead set against it?

Depending on who you ask, there was consensus, rough consensus, or no 
consensus about this document. My opinion is that rough consensus was met 
with a few very vocal people against. I support this document.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: SM <[email-masked]>
Date: Tue, 26 Jul 2011 12:58:34 -0700

Hi Ron,
At 07:30 AM 7/25/2011, Ronald Bonica wrote:
>relays will be removed from their networks. The status of RFCs 3056 
>and 3068 should not be interpreted as a recommendation to remove 
>6-to-4 at any particular time.
>

The above conflates document labels, Historic in this case, and 
advice to vendors and operators.  Redefining the meaning of Historic 
in a RFC that is not even a BCP is a bad idea.

I am fine of 6-to-4 not to be configured on by default and obsoleting 
RFCs 3056 and 3068.   I do not support the redefinition of Historic 
or the claim that there is IETF Consensus.

Regards,
-sm

---

From: Douglas Otis <[email-masked]>
Date: Tue, 26 Jul 2011 13:38:35 -0700

On 7/26/11 12:58 PM, SM wrote:
> The above conflates document labels, Historic in this case, and advice 
> to vendors and operators.  Redefining the meaning of Historic in a RFC 
> that is not even a BCP is a bad idea.
>
> RFCs 3056 and 3068.   I do not support the redefinition of Historic or 
> the claim that there is IETF Consensus.
Agreed.

-Doug

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 26 Jul 2011 16:51:27 -0400

Tom,

Sorry. I meant to copy both lists. They are both copied now.

                                Ron

> From: t.petch [mailto:[email-masked]]
> Sent: Tuesday, July 26, 2011 2:36 PM
> To: Ronald Bonica; [email-masked]
> what is
> and convert
> > - 6-to-4 should not be configured by default on any implementation
> (hosts, cpe
> routers, other)
> relays will
> clarifies

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 26 Jul 2011 14:21:59 -0700

Ron,

I believe 'draft-ietf-v6ops-6to4-advisory' is both
necessary and sufficient regardless of whether
"historic" is an appropriate characterization. So,
I don't think we need this document.

Thanks - Fred
[email-masked]  

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ronald Bonica
> Sent: Monday, July 25, 2011 7:31 AM
> To: [email-masked]
> Subject: draft-ietf-v6ops-6to4-to-historic (yet again)
> 
> Folks,
> 
> After some discussion, the IESG is attempting to determine 
> whether there is IETF consensus to do the following:
> 
> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 
> 3068 and convert their status to HISTORIC. It will also 
> contain a new section describing what it means for RFCs 3056 
> and 3068 to be classified as HISTORIC. The new section will say that:
> 
> - 6-to-4 should not be configured by default on any 
> implementation (hosts, cpe routers, other)
> - vendors will decide whether/when 6-to-4 will be removed 
> from implementations. Likewise, operators will decide 
> whether/when 6-to-4 relays will be removed from their 
> networks. The status of RFCs 3056 and 3068 should not be 
> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. 
> While it clarifies the meaning of "HISTORIC" in this 
> particular case, it does not set a precedent for any future case.
>

---

From: james woodyatt <[email-masked]>
Date: Tue, 26 Jul 2011 18:11:16 -0400

> Please post your views on this course of action by August 8, 2011.

I remain convinced that this document is unnecessary and publishing it would be silly, at best, and at worst, the simultaneous publication of 6to4-to-historic alongside 6to4-advisory, which implicitly contradict one another-- the latter says that 6to4 has an indefinite future and here's how to keep everything operational in its presence on the Internet; the former says 6to4 has no future, and it should not be used by anyone for any purpose-- may turn out to be an embarrassment for IETF.  IESG should feel very nervous about claiming there is consensus to publish this draft.  It does not appear to me like there is a rough consensus for it.

That said, I won't complain too loudly if this draft is published.  It would give me cover to ask my employers for 6to4 capability to be removed from forthcoming products that I mainly work to support.  I don't like taking features away from users when there isn't a suitable upgrade path for them, but the truth is that fielding problems from the field resulting from 6to4 failure can be pretty tiresome, and I would welcome the cover from IETF to be able to say, "Oh, you're still using 6to4?  You should turn that off.  It's deprecated by IETF now, and accordingly, we no longer support it.  Get native IPv6 service."

In other words, whether IESG means to convey this message or not, publishing 6to4-to-historic alongside the existing 6to4-advisory-- without any clear phase-out plan-- will pretty clearly imply to people like me that the official phase-out plan is to remove 6to4 from the Internet, starting as soon as vendors and operators are independently able to do so.  "Start the engines of destruction."

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Jul 2011 10:49:53 +1200

Alex,

Since 6to4 is a transition mechanism it has no long term future
*by definition*. Even if someone chooses to design a v2, who is going to
implement it?

If you have a reason to install and enable 6to4, why would the nominal
status of a couple of RFCs make you do anything different?

Of course, if implementors choose to drop the code you might not be
able to upgrade software versions - but hopefully by that time you
will have native IPv6 service anyway.

Regards
   Brian Carpenter

On 2011-07-27 03:37, Alexandru Petrescu wrote:
>> (host, cpe router, other)
>>
>> - Vendors will decide which future versions of their products will
>> support 6-to-4. It is assumed that vendors will continue to support
>> 6-to-4 until a) they are no longer economically incented to do so and
>> b) they are economically incented to remove unused features from their
>> products.
>>
>> - Operators will decide when to decommission 6-to-4 relays, if ever.
>> It is assumed that operators will continue to operate 6-to-4 relays as
>> long as they are economically incented to do so. When 6-to-4 traffic
>> levels reach zero, operators will probably begin to consider
>> decommissioning.
>>
>>> (hosts, cpe routers, other)

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Jul 2011 10:56:55 +1200

Ron,

The normal typography is 6to4, not 6-to-4. I assume the draft will
still refer to [I-D.ietf-v6ops-6to4-advisory]. Given that, I believe
the draft should proceed.

I definitely disagree with those who say this would be a misuse of
"Historic"; the words in RFC 2026 certainly cover this case
("for any other reason considered to be obsolete").

Regards
   Brian Carpenter

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Wed, 27 Jul 2011 04:23:49 +0300

> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it clarifies the meaning of "HISTORIC" in this particular case, it does not set a precedent for any future case.

This scares me.  I was on the point of saying, "But none of that stuff makes it historic!" but you then change what "Historic" means, so that I can no longer be certain ...

I'd like to see the text, but my feeling is that, no, I will not approve.  That document is too loaded with dubious claims and 6to4 hate for my liking.  And the advisory document is already perfect for expressing the _real_ problems, that really _do_ exist, for (current) 6to4 deployment.  Once again, "Historic" (in whatever sense meant) is just too strong an applied label to something which _can_ be used.  I have a very hard time seeing the sense in this document.

But let's see the text.  Perhaps you can redefine the word "Historic" in a new and interesting way.

Cheers,
Sabahattin

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 27 Jul 2011 10:43:00 +0900

Brian E Carpenter wrote:

> *by definition*.

By observation, the transition is continuing for these 16 years
since RFC1883.

						Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Wed, 27 Jul 2011 12:38:33 +1000

> will have native IPv6 service anyway.

Which is exactly why HISTORIC is NOT appropriate.

---

From: Rémi Després <[email-masked]>
Date: Wed, 27 Jul 2011 09:46:53 +0200

Le 27 juil. 2011 à 00:11, james woodyatt a écrit :

> I remain convinced that this document is unnecessary and publishing it would be silly, at best, and at worst, the simultaneous publication of 6to4-to-historic alongside 6to4-advisory, which implicitly contradict one another-- the latter says that 6to4 has an indefinite future and here's how to keep everything operational in its presence on the Internet; the former says 6to4 has no future, and it should not be used by anyone for any purpose-- may turn out to be an embarrassment for IETF.

>  IESG should feel very nervous about claiming there is consensus to publish this draft.  It does not appear to me like there is a rough consensus for it.

+1

---

From: "t.petch" <[email-masked]>
Date: Wed, 27 Jul 2011 09:32:23 +0200

I oppose this action.

I see clear evidence that 6to4 is damaging the Internet and although there are
those who can use it without causing damage, I believe that the principle is
'First, do no harm'
so the IETF has a responsibility to discourage its use.  For me, classifying it
as 'Historic' is the best way of doing this but I see that there are those dead
set against it.

Redefining 'Historic', as proposed here, can only confuse given the previous and
successful widespread use of this technical term.

Several have suggested that an alternative would be to recast this I-D as an
Applicability Statement and, while I would not see this as good as 'Historic',
since I think that  it carries less weight, I would still see that as strong
enough to get across the message - '6to4 damages the Internet - don't do it'
leaving those who know better to know better.

Tom Petch

----- Original Message -----
From: "Ronald Bonica" <[email-masked]>
To: <[email-masked]>
Sent: Monday, July 25, 2011 4:30 PM
Subject: draft-ietf-v6ops-6to4-to-historic (yet again)

as OPS Area AD>

---

From: Fred Baker <[email-masked]>
Date: Wed, 27 Jul 2011 07:09:47 -0400

On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote:

> Since 6to4 is a transition mechanism it has no long term future *by definition*. Even if someone chooses to design a v2, who is going to implement it?

Actually, I think one could argue pretty effectively that 6rd is 6to4-bis.

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Jul 2011 08:15:32 -0400

> Actually, I think one could argue pretty effectively that 6rd is 6to4-bis.

only if you're confused about the use cases for each.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Jul 2011 09:35:18 -0400

On Jul 27, 2011, at 9:07 AM, John Mann (ITS) wrote:

> In my opinion:
> 6to4 use case
> - D.I.Y setup - no ISP involvement
> - depend upon kindness of strangers to run the anycast relays
> - some users have hard-to-solve reliability problems
> - experimental / historic / not-recommended - should be off by default
> - for users who would prefer "unreliable IPv6" to "no IPv6"

close, but no cigar.

the use case for 6to4 is when
- you have a public IPv4 address
- your ISP doesn't support any kind of IPv6 access
- there's no good native v6 tunnel endpoint near your host, or your host is mobile
- you have applications for IPv6 other than to access content that is also available via IPv4, OR your hosts are set up to prefer native IPv4 over 6to4 addresses

> 
> 6rd use case
> - configuration parameters set by ISP
> - ISP runs the relays
> - apparently production quality (see free.fr)
> - for users who would prefer "no IPv6" to "unreliable Internet"
> 
> I agree that 6rd is not a replacement protocol for the 6to4 use case.
> 
> I will argue that the "6rd use case" is a replacement for the "6to4 use case".

If you have 6rd or any kind of native IPv6 available to you, you'll almost certainly prefer it to 6to4, except perhaps when needing to communicate with other hosts using 6to4.

The problem is that native IPv6 is not widely available, and will not be universally available for maybe 10 years.  

(Or maybe, never, because the deployment model in many people's minds assumes that the only reason to use IPv6 is to "access content" that will continue to be available via IPv4 indefinitely.)

> We want normal users to move past "experimental IPv6" towards "production IPv6".

I want that too.   What I object to is a denial-of-service attack on people who find 6to4 useful, just because it doesn't work as well as IPv4 for services that support both IPv4 and IPv6.

Keith

---

From: George Michaelson <[email-masked]>
Date: Wed, 27 Jul 2011 10:23:59 -0400

I have considered the issues I had facing 6to4 deprecation, and in the light of what you propose here, and other discussions, I support this course of action.

-George

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 27 Jul 2011 07:27:17 -0700

On Jul 27, 2011 4:32 AM, "Mark Townsley" <[email-masked]> wrote:
> >> Since 6to4 is a transition mechanism it has no long term future *by
definition*. Even if someone chooses to design a v2, who is going to
implement it?
> > Actually, I think one could argue pretty effectively that 6rd is
6to4-bis.

+1 as well as 6in4 or native v6.

The full requirements of 6to4 are based on currently unrealistic
requirements for no-nat (apnic is post exhaust ) and service providers to
stand up relays without a reasonable business case

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

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 27 Jul 2011 07:37:22 -0700

On Jul 27, 2011 7:20 AM, "Ted Lemon" <[email-masked]> wrote:
> This seems like an easy question to answer.   You'd implement and use
6to4v2 because it works better than the historic 6to4 protocol.

It seems like there is this deep philosophical discussion about historic
status. From what I can tell, ietf sent nat-pt to historic well before nat64
came about. Many people were using nat-pt too ... but going to historic
forced things along. It was a good choice in hindsight.

Cb

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Jul 2011 01:08:32 +1000

In message <CAD6AjGTPjhD=[email-masked]>
> stand up relays without a reasonable business case
 
There are lots of things that require no-nat.  6to4 is just one of
them.  ISP will end up providing no-nat for those that need it the
same way as they provide unfiltered port 25 for those that need it
and it also shouldn't cost more.

Yet there are relays out there and there are business cases to run
them.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Jul 2011 01:15:17 +1000

In message <[email-masked]>, Ted Lemon writes
> status of a couple of RFCs make you do anything different?

Because it will come down to "run 6to4 and be exposed to some bug"
or "not run 6to4 but be safe from the bug".  We already have vendors
saying they are thinking about pulling 6to4 from their code bases
if it becomes historic.

> This seems like an easy question to answer.   You'd implement and use 6to4v=
> 2 because it works better than the historic 6to4 protocol.

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 27 Jul 2011 08:27:54 -0700

> saying they are thinking about pulling 6to4 from their code bases

You also have content owners that say no aaaa while 6to4 is tanking
reliability stats.

Pick your battles.

Cb
> > This seems like an easy question to answer.   You'd implement and use
6to4v=

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 27 Jul 2011 11:27:58 -0400

On Jul 27, 2011, at 10:37 AM, Cameron Byrne wrote:

> > This seems like an easy question to answer.   You'd implement and use 6to4v2 because it works better than the historic 6to4 protocol.
> >
> >
> 
> It seems like there is this deep philosophical discussion about historic status. From what I can tell, ietf sent nat-pt to historic well before nat64 came about. Many people were using nat-pt too ... but going to historic forced things along. It was a good choice in hindsight.
> 

And natpt implementations still exist and are used by consenting adults. At a previous employer we were considering the business case for an implementation well after it's historic status. better solutions came along.

---

From: "Michel Py" <[email-masked]>
Date: Wed, 27 Jul 2011 08:29:36 -0700

>>> Brian E Carpenter wrote:
>>> Since 6to4 is a transition mechanism it has no long
>>> term future *by definition*. Even if someone chooses
>>> to design a v2, who is going to implement it?

free.fr, which is a third of the worldwide IPv6 traffic.

>> Fred Baker wrote:

Indeed, and it also is a transition mechanism for the very same reasons
that 6to4 is.

> Keith Moore wrote:

Even if there are different use cases indeed (as you explained it very
well yourself) you can't deny that 6rd is 6to4-bis. The difference is in
who configures/manages it, not how it works; the 6rd code base is a
superset of the 6to4. The difference is more a matter of network design
than core protocol.

Michel.

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 27 Jul 2011 08:33:47 -0700

> superset of the 6to4. The difference is more a matter of network design

6rd also evolves 6to4 with a real and traceable support model.

Cb

---

From: Tim Chown <[email-masked]>
Date: Wed, 27 Jul 2011 16:35:07 +0100

> saying they are thinking about pulling 6to4 from their code bases

I would note that RIPE-501 does not mention 6to4:
	http://www.ripe.net/ripe/docs/ripe-501
As far as I can see, it only mentions RFC4213.

I would ask what is the alternative if as Mark suggests the vendors begin removing 6to4 support?
a) use 6to4 anyway on an open platform like OpenWRT
b) use a tunnel broker - this works much better through NATs and with dynamic IPv4 addresses
c) use your $work VPN if it supports IPv6, which it could/should if your company values IPv6
d) get IPv6 from your ISP, or move to one that has it if yours does not

I suspect, but have no proof, that the huge majority of 6to4 users don't use it intentionally, and the content they are trying to reach is also available over IPv4. But for people who want to develop and use new IPv6-specific apps, then either a broker or something like OpenWRT ought to meet their needs?

Tim

---

From: Tore Anderson <[email-masked]>
Date: Wed, 27 Jul 2011 08:10:50 +0200

* Ronald Bonica

> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it clarifies the meaning of "HISTORIC" in this particular case, it does not set a precedent for any future case.

I support this approach.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com

---

From: Philip Homburg <[email-masked]>
Date: Wed, 27 Jul 2011 10:32:19 +0200

>Which is exactly why HISTORIC is NOT appropriate. 

With rfc3484-revise and the documented brokenness of 6to4, it doesn't make
any sense for implementors to offer 6to4 anyhow. So I think it would be
quite weird to keep 6to4 at standards track just to prevent some vendors from
dropping 6to4 support.

---

From: Mark Townsley <[email-masked]>
Date: Wed, 27 Jul 2011 07:31:51 -0400

+1

- Mark

---

From: "John Mann (ITS)" <[email-masked]>
Date: Wed, 27 Jul 2011 23:07:34 +1000

Hi,

In my opinion:

6to4 use case

6rd use case

I will argue that the "6rd use case" is a replacement for the "6to4 use
case".
[ And that native dual-stack is a replacement for both. ]
We want normal users to move past "experimental IPv6" towards "production
IPv6".

Thanks,
    John

---

From: Ted Lemon <[email-masked]>
Date: Wed, 27 Jul 2011 14:20:11 +0000

---

From: Erik Kline <[email-masked]>
Date: Wed, 27 Jul 2011 15:12:25 +0000

Moving 6to4 to historic does not in any way impact your ability to use
it as you wish.

6to4 support is not part of the IPv6 node requirements, as I
understand it.  Therefore I believe that any vendor (OS, router,
otherwise) could deleted 6to4 support in any release and be in
violation of anything, regardless of historic status.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Jul 2011 02:03:31 +1000

> a) use 6to4 anyway on an open platform like OpenWRT

Which may or may not still have the code.  OpenWRT could remove
support just the same as another source could.  OpenWRT is also not
widely supported by CPE vendors.  i.e. you are own your own if
something goes wrong in most (not all) cases.

> b) use a tunnel broker - this works much better through NATs and with dynamic

For which there is only experimental / ad-hoc code.  Please name
CPE vendors that support tsp?  Please name CPE vendors that support
tunnel re-configuration on re-number.

> d) get IPv6 from your ISP, or move to one that has it if yours does not

Which is not always a viable option.

> I suspect, but have no proof, that the huge majority of 6to4 users don't use 
> it intentionally, and the content they are trying to reach is also available 
> over IPv4. But for people who want to develop and use new IPv6-specific apps,
> then either a broker or something like OpenWRT ought to meet their needs?
>
> Tim

---

From: Douglas Otis <[email-masked]>
Date: Wed, 27 Jul 2011 09:22:37 -0700

+1

-Doug

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Jul 2011 02:25:34 +1000

In message <CAD6AjGThTpvH5HgGc8RbedOcJKZ=_JLR=[email-masked]>
> You also have content owners that say no aaaa while 6to4 is tanking

You have Google Chrome and Firefox already implementing HE.  You
have new address selection rules out there.  You have a dramatic
decrease in 6to4 traffic already as a result.  You have improved
throughput for the 80% of machines for which 6to4 does work.

We are yet to see the effects of Mac OS Lion both the 6to4 side
and the HE side.

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 27 Jul 2011 13:08:09 -0400

>> Actually, I think one could argue pretty effectively that 6rd is 6to4-bis. 

+2

---

From: Tim Chown <[email-masked]>
Date: Wed, 27 Jul 2011 18:25:06 +0100

> something goes wrong in most (not all) cases.

In the event OpenWRT should remove 6to4 support, just get like-minded people together (if there are lots of people that consciously want to use 6to4 for application development and testing) and roll your own.

> tunnel re-configuration on re-number.

Jeroen has answered this, but I would point out, as an example of what can be done in short time, that I had a student last year who developed a mini-ITX Linux build with tunnel broker support, and IPv6 firewall and QoS support, using a web interface driving existing tools like iptables and tc.  He chose to use the HE broker, and it's a one-time registration after which it just works without further user intervention with HE.

It would be very interesting to see brokenness figures for well-known broker prefixes as against 6to4, if anyone is gathering such data.

> Which is not always a viable option.

It is in the UK, at least.

Tim

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Jul 2011 14:18:07 -0400

On Jul 27, 2011, at 3:32 AM, t.petch wrote:

> so the IETF has a responsibility to discourage its use.  [...]

I'd like to address the point that "6to4 damages the Internet".

I do understand the content providers' argument - if 6to4 is turned on at the originator's host or network, the destination is advertising both A and AAAA records, and the AAAA record is chosen in preference to the A record, the user's experience is degraded.  Sometimes the performance is degraded marginally (but the cumulative effect of lots of small delays on a web page that loads dozens of images is large).  Sometimes it's degraded significantly because the 6to4 address doesn't work at all. Both cases matter, and they do provide a disincentive to content providers to just slap AAAA records onto their sites and be done with it.  (There are other ways of a web site utilizing v6, but they require more work.)

A lot of the arguments that I hear about 6to4 being "bad" in a universal sense seem to be based on the assumption that it's only access to "content" in the public Internet that matters.  But anyone who has followed IPv6 development should know better than that.   If access to "content" in the public Internet were all that mattered, there would have been no interest in ULAs.   It remains the case that many enterprise networks have all kinds of "internal" resources that are useful to them even if they're not publicly addressable, and are only usable from within that network or from other networks with which they have made explicit arrangements.

For better or worse, an explicit design "feature" of IPv6 is that hosts can have multiple addresses, and that different addresses might be needed in different contexts.  A host's public address might be used when contacting a public web server, but when communicating within an enterprise network or between networks each using ULA space, the host might need to use its ULA address as a source address (the other host might not have a public address or the ability to send traffic to the public IPv6 network).  

I put the word "feature" in quotes because this can be a pain in the a** for applications and users.   The default address selection rules don't really handle this case very well, nor can any set of static default rules handle this case.  Essentially what having multiple addresses per host implies is that hosts or applications need to do routing in the absence of routing information.  It shouldn't surprise anybody that the use of addresses that only work well (or at all) within a limited scope creates situations where a host will try to send traffic down a path that will never get it there, even when a different path would have worked.

Introducing IPv6 - any kind of IPv6 - into a world of hosts that already support IPv4, creates exactly this situation.

Nothing in IPv4 prohibited hosts from having multiple addresses and from advertising multiple addresses in DNS.    But this "feature" was rarely used, except in cases where all of the addresses were approximately equivalent in performance, because it didn't work well if some addresses performed better than others.  Then, as now, hosts and applications had no good way of reliably choosing which source and destination address to use.   But unlike IPv4, IPv6 deliberately chose to not only support the ability to have multiple addresses per host, but to actually expect it in a number of cases.

One way to look at the content providers' complaint against 6to4, is that 6to4 addresses are not "approximately equivalent in performance" to IPv4 addresses.  So when hosts or applications happen to choose the 6to4 address over an IPv4 address for the same resource, sometimes that choice ends up not working, or being suboptimal.  This is nothing new with 6to4.  It's inherently the case that having multiple addresses for a host that aren't equivalent in performance leads to suboptimal choices in some cases.

So essentially, the argument that "6to4 damages the Internet", is tantamount to "having multiple addresses for hosts damages the Internet".

And this is an explicitly chosen architectural "feature" of IPv6.   Blaming 6to4 for the problems caused by this "feature" is like blaming the canary carried by a coal miner for ceasing to chirp.  

(Though as it turns out, in the case of 6to4 the fix is relatively easy - just make 6to4 lower preference than either IPv4 or native IPv6 addresses except when the source and destination are both 6to4. )

--

People who are entirely engaged in providing content may have a hard time seeing any utility in 6to4.   They may ask, "if it doesn't deliver content as well as IPv4 does, what good is it?".   My answer to that question is, "what good are private networks and ULAs? "

6to4 as defined by RFC 3056 is a bit like a ULA.  It provides a way for individual hosts that have a public IPv4 address, and hosts on small networks that have a public IPv4 address, to be able to interchange IPv6 traffic.   True, it doesn't work through NAT, but it can be used as a way to provide IPv6 service within the 6to4 realm.  This lets users leverage the IPv6 protocol and IPv6 aware applications to get useful things done, that they would not have been able to do using IPv4.  Personally, I've found 6to4 useful to let me log into my home machines remotely, to remotely access file systems, to print to my home printer from work and my work printer from home, and a number of other things - all without making any application-specific arrangements.   For years I've heard from and read about other people using 6to4 in similar ways.

The mechanism defined in RFC 3068 takes a step down the slippery slope of trying to make 6to4 into a means to access the public IPv6 Internet (and vice versa).  Because it was designed in an era where managed, supported IPv6 service was not widely available, it necessarily relies on the good will of people willing to provide relay routers.  And relying on the good will of those people comes with, or should come with, decreased expectations.  Note, however that we're still in the era where managed, supported IPv6 service is not widely available.  As long as we're in that era, and as long as native v4 access is available to some users, any statements to the effect that 6to4 is evil, obsolete, historic, etc., even for the purposes of accessing the public v6 internet, are premature.  (But if you want to say that it's not reliable for this purpose, that's a defensible statement.)

The problem is that ordinary users don't know that they should have decreased expectations.  They might not even be aware that they're using 6to4, or relying on the good will of others.   

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Jul 2011 14:21:54 -0400

> I suspect, but have no proof, that the huge majority of 6to4 users don't use it intentionally, and the content they are trying to reach is also available over IPv4. But for people who want to devel…

tunnel brokers suck if the tunnel endpoint isn't near your current network location.

there are currently no universally applicable, or even widely applicable, v6-over-v4 solutions.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Jul 2011 14:25:20 -0400

On Jul 27, 2011, at 4:32 AM, Philip Homburg wrote:

> any sense for implementors to offer 6to4 anyhow.

False.  It makes even more sense to offer 6to4 because it significantly decreases the chance that it will cause a bad experience for users of services that provide both v4 and v6 addresses, while increasing the chance letting local hosts/users talk to v6-only services/hosts.

> So I think it would be

Vendors can drop 6to4 support, or for that matter any other feature, anytime they wish.  They don't need permission from IETF to do that.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Jul 2011 14:28:47 -0400

> Moving 6to4 to historic does not in any way impact your ability to use

False.  Moving 6to4 to Historic is inviting people to mount denial of service attacks on things that actually work for people today.  Moving 6to4 to Historic will also invite vendors to remove 6to4 support from future versions or updates of their products, forcing users to make difficult choices between using 6to4 on one hand and changing equipment or vendors on another.

There's no reason to cause that kind of collateral damage.   Denial of service attacks are completely inappropriate.

> violation of anything, regardless of historic status.

Nothing that IETF specifies requires 6to4.   Vendors can indeed delete it if they want to.  But IETF should not recommend that they do so, or imply that they should do so.

Keith

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 28 Jul 2011 03:42:07 +0900

> I put the word "feature" in quotes because this can be a pain in the a** 

It means it's IPv6 which is damaging the Internet.

> Introducing IPv6 - any kind of IPv6 - into a world of hosts that 

A revised IPv6 and transport which can properly handle multiple
addresses can happily coexist with IPv4.

However, as IPv6 is totally broken, it is better to start with
a clean slate than to revise it. Or, more practically, just stick
to IPv4.

> Nothing in IPv4 prohibited hosts from having multiple addresses

IPv4 with revised transport is far better than the current IPv6
and transport.

> And this is an explicitly chosen architectural "feature" of IPv6.

which is partly why IPv6 is broken and harmful. Proper support
of multihoming can be done only at the transport layer and above.

						Masataka Ohta

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Jul 2011 14:45:01 -0400

Thank you Keith for restating the problem.

>>>>> "Keith" == Keith Moore <[email-masked]> writes:
    Keith> So essentially, the argument that "6to4 damages the
    Keith> Internet", is tantamount to "having multiple addresses for
    Keith> hosts damages the Internet". 

+1

...

    Keith> People who are entirely engaged in providing content may have
    Keith> a hard time seeing any utility in 6to4.   They may ask, "if
    Keith> it doesn't deliver content as well as IPv4 does, what good is
    Keith> it?".   My answer to that question is, "what good are private
    Keith> networks and ULAs? " 

And, we need to remember that the IETF is the stewart of the IP protocol
suite, not the stewart of the Internet.

Perhaps we actually need Klensin's Internet Standard series, not as a
two-level or something else, but as agreement as to what happens on the
public Internet, vs what might happen behind closed doors.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 27 Jul 2011 14:52:58 -0400

On Wed, Jul 27, 2011 at 14:18, Keith Moore <[email-masked]>wrote:

> So essentially, the argument that "6to4 damages the Internet", is
> tantamount to "having multiple addresses for hosts damages the Internet".
>
> *And this is an explicitly chosen architectural "feature" of IPv6.*
>

Having multiple addresses for hosts damages the Internet
Multiple addresses for hosts damages the Internet
-> IPv6 damages the Internet

I give up. I wish you a productive discussion from here on.

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Jul 2011 15:00:19 -0400

> It means it's IPv6 which is damaging the Internet.

Except that the (v4) Internet is already doing its best to damage itself.   So the choice is between a thoroughly brain-damaged v4 Internet that is continually getting worse, and a somewhat less brain-damaged v6 Internet that has at least some chance of having a few things fixed - though all of the existing successful "content" and services are optimized for the v4 Internet.

But again, fixing the 6to4 version of this problem is relatively easy, and pretty much everybody agrees on mechanisms that will fix the problem.  The only disagreement is how to make the message as clear and effective as possible, and there are glimmers of hope in that area.

People just shouldn't get lulled into thinking that the problem will go away once 6to4 is fixed.

Keith

---

From: Roger Jørgensen <[email-masked]>
Date: Wed, 27 Jul 2011 21:25:01 +0200

On Wed, Jul 27, 2011 at 3:07 PM, John Mann (ITS) <[email-masked]> wrote:
<snip>
> We want normal users to move past "experimental IPv6" towards "production

Exactly, we should focus on doing production IPv6, not wasting our
time on something that run on top of something else, whatever it's
called (are way too many to choice from already and I will recommend
anyone that ask me to never walk down that road, never).

So, can we please stop this never ending SPAMMING with regards to 6to4?

It is a total waste of time, really Keith, please stop. pretty please stop.

-- 

Roger Jorgensen           |

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 27 Jul 2011 21:50:25 +0200

Le 27/07/2011 21:25, Roger Jørgensen a écrit :
> On Wed, Jul 27, 2011 at 3:07 PM, John Mann (ITS)<[email-masked]>  wrote:
> <snip>

I believe 6to4 is useful dont make it historic without a clear 
replacement strategy which is backwards compatible with installed base.

open source and no need to fill in forms on web pages.

Alex

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 28 Jul 2011 06:22:14 +0900

Keith Moore wrote:

> Except that the (v4) Internet is already doing its best to damage
> itself.   So the choice is between a thoroughly brain-damaged
> v4 Internet that is continually getting worse, and a somewhat
> less brain-damaged v6 Internet that has at least some chance
>  of having a few things fixed

You are wrong. While IPv4 is demonstratively usable, IPv6 along
with ND is too bloated that it is totally unusable.

For example, packet too big for multicast PMTUD causes ICMPv6
implosions which may be used for DoS.

While IPv4 guarantees that 516B payload receivable by any host,
IPv6 can't. Because of indefinitely length header options, some
of which (e.g. options for mobility) are inserted without
trasnport/application control, there is no room, not even 1B,
reserved for payload.

And, the worst problem is that 16B address, thanks to poor
estimation of RFC1715, is impossible to remember.

					Masataka Ohta

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Jul 2011 18:26:43 -0400

>>>>> "Roger" == Roger Jørgensen <[email-masked]> writes:

    Roger> Exactly, we should focus on doing production IPv6, not wasting our
    Roger> time on something that run on top of something else, whatever
    Roger> it's

So, in your opinion, a production host will never have more than
one address?

This is the fundamental problem.  6to4 is just the thing shining the
light on the problem.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 28 Jul 2011 01:32:53 +0200

After reading your text, let me share my experience:

I struggled hard to get a class C w/o NAT.  As hard as that was it was
still easier than obtaining native IPv6.  I wont struggle to get native
ipv6 too.

We use 6to4 on a frontend machine, and we use native IPv6 out of that
6to4 on several subnets behind, hence end machines are native ipv6 if i
can say so.

This is not much for content browsing, but for proudly ping6 an ipv6
node across the globe.

In the past year_s_ we have set up and down several kinds of 6-4 tunnels
manually, brokered, agreed.  We required vendors to include this and
that kind of tunnel in their sw/hw.

We have moved physically and we will move again soon.  We are guaranteed
continuity of this class C no nat, and yet still no IPv6 tunnel up and
downs.  The only thing that was stable during this time was 6to4, and
improved support appeared more and more.

I would also add as information only, that the environment where this
happens, and where i have no control, is where an ethernet seting with
many office-type users, where dhcp is not used, if you can imagine that.
There are many reasons technical and human for that being so.  And
manual assignment (vs dhcp) is not historical - its there in every pc.

Alex

Le 26/07/2011 16:14, Tim Chown a écrit :
> Our own users made use of 6to4 maybe 8+ years ago, and at the time
> it was handy to have.  Today though we're not aware of any of our
> users running 6to4 intentionally. We have IPv6 native on site, and
> anyone who wants home IPv6 connectivity either goes to an ISP that
> provides it, e.g. A&A in the UK, or they use a tunnel broker. Brokers
> have the additional benefit of working through NATs and with dynamic
> IPv4 endpoints.
>
> Our site sees about 1-2% of all inbound traffic being IPv6, and of
> that less than 1% is 6to4, and this is only likely to fall further
> with rfc3484-bis. What 6to4 we do see is probably reasonably robust
> in that our return path uses the JANET-provided 6to4 relay.
>
> Most operating systems either already, or before long will, support
> rfc3484-bis, which means hosts should use IPv4 in preference to 6to4
> where both are available.  To choose to use 6to4, the user would need
> to consciously change their 3484 policy table, assuming their OS
> supports that (Linux and Windows do, MacOS X Lion appears not to).
>
> Geoff Huston has presented data at IETF80 showing 6to4 brokenness
> and performance. We now have 'Happy Eyeballs Lite' implemented in
> Chrome and (I believe, not tested it yet) Firefox, which means the
> browser can adapt to broken IPv6, whether caused by 6to4 or other
> factors.
>
> The 6to4-advisory draft suggests off-by-default, which I agree with,
> and use of relays to improve user experience. The problem is we can't
> expect every site/ISP to run a relay (or multi-address with 6to4) so
> there will inevitably always be problems with the 3068 mode of 6to4.
>
> We measured rogue RAs over a two year period on our wireless
> network. About 60% of the time at least one host was emitting a
> rogue 6to4-based RA. While these were mitigated by ramond, it would
> be good to see vendors fix this; it's not just MS ICS.  Happy
> Eyeballs is a mitigation for such rogue RAs also.
>
> So in summary, in practice 3484-bis and the 6to4-advisory
> off-by-default will further reduce what little use there is of 6to4
> now, and happy eyeballs will mitigate any remaining instances of its
> use that are bad. So whether 6to4 is tagged Historic or not, it
> should be causing significantly less harm.
>
> Tim _______________________________________________ Ietf mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/ietf

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Jul 2011 09:36:34 +1000

In message <[email-masked]>, Jeroen Massar writes:
> On 2011-07-27 20:21 , Keith Moore wrote:
> >> I suspect, but have no proof, that the huge majority of 6to4 users don't u
> se it intentionally, and the content they are trying to reach is also availab
> le over IPv4. But for people who want to develop and use new IPv6-specific ap
> ps, then either a broker or something like OpenWRT ought to meet their needs?
> > 
> Let me rewrite that sentence for you:
> 
>  "transition mechanisms suck if the tunnel endpoint isn't near your
> current network location"
> 
> It does not matter much if that mechanism is static proto-41 (6in4),
> 6to4, AYIYA, TSP, PPTP, HTTP Proxies or whatever, there is going to be a
> bit more latency if they are not directly next to you. Not much you can
> do about except deploy more of them or
> 
> And this will always be the case unless you deploy enough of them in all
> places possible. For SixXS we are at 48 boxes around the world,
> Hurricane has 25 and Gogo6 has 4 of them of their own for Freenet6 and
> then there are 4 others at other organizations and there are a couple of
> other services out there which provide tunnels see:

Is there *one* tunnel management protocol that they all support or
does a cpe vendor have to implement multiple ones to reach them
all?  I'm pretty sure I know the answer to this question but I'd
love to be proved wrong.

One of the advantages of 6to4 anycast is that it is just needs a
check box to turn on and off.  Everybody speaks the same thing.

Another advantage of 6to4 is it doesn't require manual intervention
on renumber events.  Manual tunnel don't pass muster.

Another advantage of 6to4 is you don't have to register.  For most of
the tunnel brokers you have to register.

>  http://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers
> 
> For your set of requirements maybe but especially Tunnel Brokers are
> working very well for a lot of people and if one sees the traffic stats
> on Teredo and 6to4 nodes due to this little thing called NNTP I would
> state that those are doing quite fine too for giving access to what
> people need to get to.
> 
> Your major requirement seems to involve latency though, thus as such,
> there is only one thing to do, get one of those boxes deployed locally
> to your endpoint.
> 
> Do note to yourself that the next issue you will run into that the
> service you are actually contacting will be far away, and you suddenly
> understand that you need that Akamai content box and a Google one and
> various other closeby too ;)
> 
> If you want to solve your problem though, I guess for HE you'll have to
> give them connectivity to their network and space in a rack for a box,
> gogo6 will sell you a box and for SixXS you provide the box+connectivity
> and we'll set up the software for free for you and handle the tunneling
> completely.
> 
> Greets,
>  Jeroen

---

From: james woodyatt <[email-masked]>
Date: Wed, 27 Jul 2011 21:56:51 -0400

On Jul 27, 2011, at 4:32 AM, Philip Homburg wrote:
> 
> So I think it would be quite weird to keep 6to4 at standards track just to prevent some vendors from dropping 6to4 support. 

As one of those implementers-- as in, it will probably be *my* commit to the repository that does "rm $XNU/bsd/net/if_stf.c"—- I now feel compelled to reiterate that I would prefer a more controlled phase-out plan than, "equipment vendors and operators are free to commence the destruction of 6to4 at their individual convenience and without further warning to the user community."

In the absence of a coherent instruction from IETF for a phase-out plan, declaring this protocol historic under the current proposed language, will do precisely that.  Please please please, if IETF wants 6to4 to die, then publish a phase-out plan so that the current users of 6to4 can have fair warning before the relays go dark and forthcoming hardware/software upgrades rip the feature out from under them.

---

From: "Michel Py" <[email-masked]>
Date: Wed, 27 Jul 2011 20:12:43 -0700

James,

> james woodyatt wrote:
> I now feel compelled to reiterate that I would prefer a more
> controlled phase-out plan than, "equipment vendors and operators
> are free to commence the destruction of 6to4 at their individual
> convenience and without further warning to the user community."

According to this:
http://www.pam2010.ethz.ch/papers/full-length/15.pdf
Slightly less than 50% of IPv6 traffic comes from a MacOS client (fig
3); about 90% MacOS hits is 6to4, which possibly means (to me) that this
piece of 6to4 MacOS software of yours represents a third of global IPv6
traffic.

Would you care to comment on the numbers?

Also, according to Cisco's blog (that links to the document above):
http://blogs.cisco.com/sp/france-is-famous-for-fine-wine-cheese-and-now-
ipv6/
-or-
http://tinyurl.com/5u3eorn
"France is responsible for more than half of current IPv6 traffic
worldwide"; I can positively confirm that Free (AS12322) that
contributes to most of the French IPv6 native hits is delivering
"native" IPv6 to their eyeballs using 6rd and that they are indeed the
800-pound gorilla of French IPv6 traffic, no contest.

So, a third of IPv6 traffic is James' MacOS 6to4 software, another third
is AS12322's 6rd (which, given recent comments, is indeed 6to4-bis) and
we want to declare 6to4 historic?

Michel.

---

From: "Brzozowski, John" <[email-masked]>
Date: Thu, 28 Jul 2011 03:15:24 +0000

>From an operators point of view, specifically one that has deployed 6to4
relays, use of the same should not be encouraged.

I fully hope and expect the use of 6to4 to systematically decrease over
time so the associated infrastructure can be decommissioned.

While we have seen issues related to 6to4 decrease recently the deployment
of the same over the years, in particular open relays, has grossly
complicated deploying 6to4 in a reliable manner.

I have not been able to keep up with all the emails and threads related to
this topic, I apologize for this.

The bottom line from my point of view is that we (the IETF) should do
something to discourage the use of the same.

John
=========================================
John Jason Brzozowski
Comcast Cable
e) mailto:[email-masked]
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=========================================

On 7/27/11 2:18 PM, "Keith Moore" <[email-masked]> wrote:

>I do understand the content providers' argument - if 6to4 is turned on at
>the originator's host or network, the destination is advertising both A
>and AAAA records, and the AAAA record is chosen in preference to the A
>record, the user's experience is degraded.  Sometimes the performance is
>degraded marginally (but the cumulative effect of lots of small delays on
>a web page that loads dozens of images is large).  Sometimes it's
>degraded significantly because the 6to4 address doesn't work at all. Both
>cases matter, and they do provide a disincentive to content providers to
>just slap AAAA records onto their sites and be done with it.  (There are
>other ways of a web site utilizing v6, but they require more work.)
>
>A lot of the arguments that I hear about 6to4 being "bad" in a universal
>sense seem to be based on the assumption that it's only access to
>"content" in the public Internet that matters.  But anyone who has
>followed IPv6 development should know better than that.   If access to
>"content" in the public Internet were all that mattered, there would have
>been no interest in ULAs.   It remains the case that many enterprise
>networks have all kinds of "internal" resources that are useful to them
>even if they're not publicly addressable, and are only usable from within
>that network or from other networks with which they have made explicit
>arrangements.
>
>For better or worse, an explicit design "feature" of IPv6 is that hosts
>can have multiple addresses, and that different addresses might be needed
>in different contexts.  A host's public address might be used when
>contacting a public web server, but when communicating within an
>enterprise network or between networks each using ULA space, the host
>might need to use its ULA address as a source address (the other host
>might not have a public address or the ability to send traffic to the
>public IPv6 network).
>
>for applications and users.   The default address selection rules don't
>really handle this case very well, nor can any set of static default
>rules handle this case.  Essentially what having multiple addresses per
>host implies is that hosts or applications need to do routing in the
>absence of routing information.  It shouldn't surprise anybody that the
>use of addresses that only work well (or at all) within a limited scope
>creates situations where a host will try to send traffic down a path that
>will never get it there, even when a different path would have worked.
>
>Introducing IPv6 - any kind of IPv6 - into a world of hosts that already
>support IPv4, creates exactly this situation.
>
>Nothing in IPv4 prohibited hosts from having multiple addresses and from
>advertising multiple addresses in DNS.    But this "feature" was rarely
>used, except in cases where all of the addresses were approximately
>equivalent in performance, because it didn't work well if some addresses
>performed better than others.  Then, as now, hosts and applications had
>no good way of reliably choosing which source and destination address to
>use.   But unlike IPv4, IPv6 deliberately chose to not only support the
>ability to have multiple addresses per host, but to actually expect it in
>a number of cases.
>
>One way to look at the content providers' complaint against 6to4, is that
>6to4 addresses are not "approximately equivalent in performance" to IPv4
>addresses.  So when hosts or applications happen to choose the 6to4
>address over an IPv4 address for the same resource, sometimes that choice
>ends up not working, or being suboptimal.  This is nothing new with 6to4.
> It's inherently the case that having multiple addresses for a host that
>aren't equivalent in performance leads to suboptimal choices in some
>cases.
>
>Blaming 6to4 for the problems caused by this "feature" is like blaming
>the canary carried by a coal miner for ceasing to chirp.
>
>(Though as it turns out, in the case of 6to4 the fix is relatively easy -
>just make 6to4 lower preference than either IPv4 or native IPv6 addresses
>except when the source and destination are both 6to4. )
>
>--
>
>People who are entirely engaged in providing content may have a hard time
>seeing any utility in 6to4.   They may ask, "if it doesn't deliver
>content as well as IPv4 does, what good is it?".   My answer to that
>question is, "what good are private networks and ULAs? "
>
>6to4 as defined by RFC 3056 is a bit like a ULA.  It provides a way for
>individual hosts that have a public IPv4 address, and hosts on small
>networks that have a public IPv4 address, to be able to interchange IPv6
>traffic.   True, it doesn't work through NAT, but it can be used as a way
>to provide IPv6 service within the 6to4 realm.  This lets users leverage
>the IPv6 protocol and IPv6 aware applications to get useful things done,
>that they would not have been able to do using IPv4.  Personally, I've
>found 6to4 useful to let me log into my home machines remotely, to
>remotely access file systems, to print to my home printer from work and
>my work printer from home, and a number of other things - all without
>making any application-specific arrangements.   For years I've heard from
>and read about other people using 6to4 in similar ways.
>
>The mechanism defined in RFC 3068 takes a step down the slippery slope of
>trying to make 6to4 into a means to access the public IPv6 Internet (and
>vice versa).  Because it was designed in an era where managed, supported
>IPv6 service was not widely available, it necessarily relies on the good
>will of people willing to provide relay routers.  And relying on the good
>will of those people comes with, or should come with, decreased
>expectations.  Note, however that we're still in the era where managed,
>supported IPv6 service is not widely available.  As long as we're in that
>era, and as long as native v4 access is available to some users, any
>statements to the effect that 6to4 is evil, obsolete, historic, etc.,
>even for the purposes of accessing the public v6 internet, are premature.
> (But if you want to say that it's not reliable for this purpose, that's
>a defensible statement.)
>
>The problem is that ordinary users don't know that they should have
>decreased expectations.  They might not even be aware that they're using
>6to4, or relying on the good will of others.
>
>Keith
>
>
>

---

From: TJ <[email-masked]>
Date: Wed, 27 Jul 2011 23:41:38 -0400

To be fair - I don't think anyone is saying "We should totally encourage
6to4!", even in the short-term ... or any other auto-tunneling transition
mechanism, really.

In fact, I think the debate here largely stems from a valid desire to
discourage 6to4.
Note: That goal, I am in favor of (recommending that 6to4 be disabled by
default on client platforms).

However, the proposals on the table seek to reclassify 6to4 as historic -
something that has raised a noticeable amount of debate about 1) what
historic really means and/or 2) what impact that re-classification may have
on currently-functional 6to4 usage today.

/TJ ... who wishes to note that 6to4 works *just fine* ... except when it
doesn't.
PS - And in those cases, proper address selection is a much better solution
(IMHO) than hitting this screw with a hammer.

---

From: james woodyatt <[email-masked]>
Date: Thu, 28 Jul 2011 01:30:38 -0400

> Would you care to comment on the numbers?

p1.  Those numbers are badly outdated.

p2.  Hits originating from Mac OS X hosts with their 6to4 tunnels disabled probably account for much of that traffic when it was measured.  At that time, Apple's operating systems were the most commonly deployed implementations with IPv6 stacks enabled and running in the stock install.  That isn't true any more.

p3.  Recent measurements of hits originating from Mac OS X hosts on 6to4 prefixed networks are dramatically smaller than when those measurements were taken, because Apple has updated Mac OS X 10.6 and 10.7 with significantly different behavior that will avoid using broken or underperforming 6to4 links.

p4.  Yes, older gear remains in the field, and some of it doesn't even have a software upgrade path.  That gear, no doubt, accounts for a substantial portion of admittedly not very large flows through public 6to4 relays at present.  I think the measurements we've all seen at the technical plenary show that 6to4 is a small percentage of the total world IPv6 traffic now, which again is an embarrassingly small fraction of global Internet traffic.

p5.  We should all be mindful that we're talking about a very small, and as far as I can tell, a not very critical segment of anybody's user base.  Which, nevertheless, is still somehow to blame for holding up the global roll-out of IPv6 content.  (I'm not sure even the legendary Gnomes of Zürich could do that.)

What else is there to say?  Oh, I remember now.  Those of you 6to4-haters with Lion installed now.  Please open a Terminal.app window and type this command:

  $ sudo sysctl -w net.inet6.icmp6.nd6_accept_6to4=0

That will make the IPv6 stack treat all Prefix Information Options with 2002::/16 prefixed addresses in them as if the A bit is always zero.  The system will not auto-configure any 6to4 addresses on any interfaces, even a stf interface.

Oh, you want that all the time?  Add a line to /etc/sysctl.conf.  Done.  No more 6to4 for you.  Anywhere.  Let me know if that changes anything noticeably to the better for you.  (On the plus side, it should spare you from suffering any indignity at the hands of a 6to4-PMT service.)

---

From: "Michel Py" <[email-masked]>
Date: Wed, 27 Jul 2011 23:07:40 -0700

James,

If I remember correctly, you mentioned a bit ago that your job required
you had native IPv6 at home. 

Question: Does an ISP providing you IPv6 out of the CPE box (meaning,
without any software other than dual-stack on the hosts) qualify as
native IPv6 if, behind the scenes, they use a tunnel broker, or 6rd?

> p1.  Those numbers are badly outdated.

What is your reading on 6rd numbers? And if these numbers are badly
outdated, where do you place the MacOS IPv6 traffic distribution today?

> p3.  Recent measurements of hits originating from Mac OS X
> hosts on 6to4 prefixed networks are dramatically smaller
> than when those measurements were taken, because Apple has
> updated Mac OS X 10.6 and 10.7 with significantly different
> behavior that will avoid using broken or underperforming
> 6to4 links.

So where does the new behavior switch the traffic to,
from 10.6 to 10.7? Back to IPv4? Or some other method?
Maybe Apple is using Teredo? (ducks) :P

> [..] the total world IPv6 traffic now, which again is an
> embarrassingly small fraction of global Internet traffic.

That is another debate.

Michel.

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Jul 2011 02:45:52 -0400

On Jul 28, 2011, at 1:30 AM, james woodyatt wrote:

>  I think the measurements we've all seen at the technical plenary show that 6to4 is a small percentage of the total world IPv6 traffic now, which again is an embarrassingly small fraction of global Internet traffic.

What I saw from different presentations seemed to indicate that 6to4 was around 30% of total IPv6 traffic.  

I think it's hard to conclude much from that in terms of future use of 6to4 vs. native.  As you point out, more and more stacks are disabling 6to4 by default.  But when the native v6 traffic is dominated by a single AS, it's hard to use that as an indication of how much growth there will be in use of v6.

Bottom line: we still have our work cut out for us.

Keith

---

From: Philip Homburg <[email-masked]>
Date: Thu, 28 Jul 2011 09:50:59 +0200

>(IMHO) than hitting this screw with a hammer.

I think the problem is that we don't know how to do 'proper' address
selection. It would be nice if 5 or 10 years ago there would have been a good
standard to do address selection. Today, we are just in the stage of doing
more experiments.

There is one thing that works well. And that is, you only assign global
IPv6 addresses to a host if global IPv6 connectivity is at least as good as
IPv4 connectivity.

We want large scale deployment of IPv6 today not some time in the future
when we finally figured out address selection. And that means that today we
have to make sure that users don't end up with unreliable IPv6 connections.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 28 Jul 2011 17:08:01 +0900

Philip Homburg wrote:

> selection.

I know and it's trivially easy.

> It would be nice if 5 or 10 years ago there would have been a good
> standard to do address selection.

11 years ago in draft-ohta-e2e-multihoming-00.txt, I wrote:

   End systems (hosts) are end systems. To make the end to end principle
   effectively work, the end systems must have all the available
   knowledge to make decisions by the end systems themselves.

   With regard to multihoming, when an end system want to communicate
   with a multihomed end system, the end system must be able to select
   most appropriate (based on the local information) destination address
   of the multihomed end system.

which means an end system should have a full routing table, IGP
metrics in which tell the end system what is the best address of
its multihomed peer. Full routing table should and can, of course,
be small.

The approach is totally against node/router separation of IPv6 to
make routers, the intermediate systems, a lot more intelligent
than nodes, the end systems, which is partly why IPv6 is hopeless.

						Masataka Ohta

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Jul 2011 07:50:38 -0400

> IPv6 addresses to a host if global IPv6 connectivity is at least as good as

In general, all of a host's addresses (at least, those in the same preference class in the address selection algorithm) need to work equally well from everywhere.

But even that might not be sufficient.   Fred Baker has recently been citing a different example of the same problem:  Imagine a future where hosts on a network have both v6 and legacy v4 through stateful NAT.  Because the v6 connection works well most of the time, hosts tend to choose v6 destinations, and sites reduce the capacity of their NATs over time.  Then the v6 connection fails, and suddenly everything falls back to v4, and the connections through NAT also fail for lack of sufficient capacity to handle the load.

Note that in some sense this is a perceptual problem.   If instead of a v4 and a v6 address, each of those hosts had two v6 addresses and two different egress paths, the network engineers would be more likely to understand that both external connections needed to be of equal capacity - just like multihomed v4 networks with a single prefix now.   And in some sense there's nothing wrong with having a v6 connection for most things and a small v4 NAT for connecting to legacy v4 services, as long as you don't think of the v4 path as a fallback - you're willing to accept that loss of the v6 connection is for practical purposes loss of external connectivity.   The problem is that if you think of the v4 NAT as a fallback for the v6 service, AND you don't drastically overprovision the NAT.

> have to make sure that users don't end up with unreliable IPv6 connections.

If you make the constraint that nobody can use IPv6 at all until the IPv6 connections work as well in all cases as the IPv4 connections, that creates a huge barrier to the universal deployment of IPv6 - which already has enough barriers as it is.  

A less onerous constraint is that less reliable IPv6 connections don't get used in preference to more reliable IPv4 connections.  We're lucky in the case of 6to4 in that it has a well-known prefix that allows the traffic to be distinguished from other v6 traffic.   But it's still necessary to manage expectations about IPv4 as a fallback path.

Keith

---

From: Philip Homburg <[email-masked]>
Date: Thu, 28 Jul 2011 14:20:07 +0200

In your letter dated Thu, 28 Jul 2011 07:50:38 -0400 you wrote:
> In general, all of a host's addresses (at least, those in the same
> preference class in the address selection algorithm) need to work
> equally well from everywhere.
> 
> But even that might not be sufficient.   Fred Baker has recently
> been citing a different example of the same problem:  Imagine a
> future where hosts on a network have both v6 and legacy v4 through
> stateful NAT.  Because the v6 connection works well most of the
> time, hosts tend to choose v6 destinations, and sites reduce the
> capacity of their NATs over time.  Then the v6 connection fails,
> and suddenly everything falls back to v4, and the connections
> through NAT also fail for lack of sufficient capacity to handle
> the load.

I'm sure some manager will just require this to work. But I would say that
this is just supposed to fail.

If you had in the past just an IPv4 connection and it went down, there would
be no Internet access. Same thing in the future. If your IPv6 connection goes
down you don't have an Internet conenction.

It would be different if the NAT was there just to connect to a very specific
collection of legacy IPv4 sites. But that can be solved easily but just
routing those IPv4 prefixes to the NAT. 

If you want the NAT to provide full redundancy, then it has to be scaled to
accept full load. Otherwise, no IPv6 just means no Internet. Very simple.

> If you make the constraint that nobody can use IPv6 at all until
> the IPv6 connections work as well in all cases as the IPv4 connections,
> that creates a huge barrier to the universal deployment of IPv6 -
> which already has enough barriers as it is.

To some extent that is exactly the way it is. 

Suppose that a significant fraction of popular websites would have IPv6
addresses that don't actually work. Then essentially no ISP would enable IPv6
for their customers because their customers would suffer.

At the moment, most servers that do have IPv6 addresses seem to actually
support IPv6 so this doesn't seem to be a big problem.

But we don't know what the future might bring. If there would be a sudden
rush of servers that have PMTU problems, then we could have a very serious
problem. 

> A less onerous constraint is that less reliable IPv6 connections
> don't get used in preference to more reliable IPv4 connections.
> We're lucky in the case of 6to4 in that it has a well-known prefix
> that allows the traffic to be distinguished from other v6 traffic.
> But it's still necessary to manage expectations about IPv4 as a
> fallback path.

Happy Eyeballs can solve a lot of problems where a connection will fail
completely or have a high latency. But HE support is far from universal and
so far experience is limited to TCP.

But it doesn't do anything for PMTU problems. 

It also doesn't do anything for real-time streaming applications.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 28 Jul 2011 14:45:13 +0200

>its multihomed peer. Full routing table should and can, of course,

Even in the unlikely case that it would be feasible to give every host a
complete copy of the DFZ routing table... That still would leave a lot of
issues open...
1) End-to-end latency. Maybe some future generation BGP provides that, but
   that doesn't help now.
2) For 6to4, the use of anycase. You probably need a link-state routing 
   protocol to allow a host to figure out which relays are going to be used on
   a give path.
3) Filters in firewalls. I'd love to see a routing protocol that reports the
   settings of all firewalls in the world :-)
4) Other performance metrics, like jitter, packets loss, etc.

Maybe you can do some experiments and report on how well your draft works for
deciding when to prefer a 6to4 address over IPv4.

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 28 Jul 2011 10:20:26 -0400

> From: Michel Py [[email-masked]]
> 

Also:

    One reason that may explain France’s early adoption of IPv6 is
    that France has formed a multitude of valuable IPv6-based
    associations on the past decade. This activity has greatly
    contributed to the acquisition and dissemination of IPv6
    knowledge. These organizations consist of the G6, whose primary
    task is IPv6 experimentation and information exchange. The G6 was
    founded in 1995 by researchers in academia and industry. G6’s
    overall goal is the gradual building of a new infrastructure
    required for the Internet to survive. The G6, like Cisco, is
    focused on an effective and seamless transition IPv4 to IPv6. It
    is the primary catalyst for advances in IPv6 networking in France.

In other words, very early (15 years ago), the French Internet
community formed an organization to move IPv6 forward through
coordination and persuasion rather than by preaching from the outside.

In the larger Internet, I've seen a remarkable absence of that sort
of coordination.

Dale

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 28 Jul 2011 08:04:17 -0700

On Jul 28, 2011 1:08 AM, "Philip Homburg" <[email-masked]> wrote:
>
> In your letter dated Wed, 27 Jul 2011 21:56:51 -0400 you wrote:
> > In the absence of a coherent instruction from IETF for a phase-out
> > plan, declaring this protocol historic under the current proposed
> > language, will do precisely that.  Please please please, if IETF
> > wants 6to4 to die, then publish a phase-out plan so that the
> > current users of 6to4 can have fair warning before the relays go
> > dark and forthcoming hardware/software upgrades rip the feature
> > out from under them.
>
> I would hope that big companies like Apple would actually do an impact
> analysis before removing a feature.
>

Like how Apple does not support Flash in iOS?

Just one example where a visionary drops an inferior solution to force a
better one.

This is also known as cracking some eggs to make an omelet.

Cb

> Big content providers can measure how much 6to4 is enabled, so they can
> probably say something about trends. But that doesn't say much about how
many
> users actually care about 6to4. Vendors seem to be best equiped to analyse
> the users' need for 6to4.
>
> I don't think relay operators have expressed a desire for a specific cut
off
> date. So I guess they just figure out for themselves when to switch off
the
> relays.

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 27 Jul 2011 18:28:37 +0200

On 2011-07-27 18:03 , Mark Andrews wrote:
[..]
> For which there is only experimental / ad-hoc code.

You call my code Experimental/ad-hoc? :)

Like a good whiskey it matured over the years and hopefully soon I will
be releasing the next edition of AICCU which solves, at least in that
implementation, a couple of quirks that we have encountered in the
recent years.

> Please name

I don't know about TSP, but for the combination of TIC/heartbeat + AYIYA
in some cases there are a variety of vendors, amongst which AVM
Fritz!Box, Draytek, ZyXel Motorola, and various others I tend to forget
;) I unfortunately do not have an exact list of devices/models as I had
nothing to do with them, we just get users saying that they have a
device which supports it ;)

The fun part though with CPEs is that they tend to sit on the public IP
address, which is also the reason why the Fritz!Box only does TIC/heartbeat.

And of course every self respecting distribtion has support for it too
by just adding AICCU, that includes the various WRTs, pfSense, m0nowall,
Astaro and many many others.

As you said, everybody can decide themselves what options they add ;)

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 27 Jul 2011 20:51:42 +0200

Greets,
 Jeroen

---

From: Philip Homburg <[email-masked]>
Date: Thu, 28 Jul 2011 10:08:11 +0200

Big content providers can measure how much 6to4 is enabled, so they can
probably say something about trends. But that doesn't say much about how many
users actually care about 6to4. Vendors seem to be best equiped to analyse 
the users' need for 6to4.

I don't think relay operators have expressed a desire for a specific cut off 
date. So I guess they just figure out for themselves when to switch off the
relays.

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 28 Jul 2011 11:12:17 +0200

On 2011-07-28 01:36 , Mark Andrews wrote:
[..]
> all?  I'm pretty sure I know the answer to this question but I'd

There is no 'one' solution to the problems that they are solving.

As such there tend to be a combo of:
 - static proto-41 tunnel
 - 6to4
 - 6rd
 - TSP => dynamic NATted addresses
 - proto-41 + heartbeat + TIC => dynamic public addresses
 - AYIYA + TIC => dynamic NATted addresses

TSP conveys configurartion information inline with the UDP packets.
TIC is solely for configuration information and does not do tunneling
but can be used for all proto-41/heartbeat/AYIYA protocols (and for
instance AVM chose to only do proto-41 + heartbeat as their devices
always have public IPv4 IPs).

Teredo is only for a single host thus is not useful for CPEs and thus
not included in them.

> check box to turn on and off.  Everybody speaks the same thing.

Except that it does not work behind a NAT and most people do sit behind
a NAT.

Next to that those anycasts are even rarer around the world and on top
of that it is hard to figure out issues when they are there (although
some people have tricks to apparently debug them, the anycast on both
IPv4 and IPv6 requires one to contact a lot of folks).

The big advantage over a known tunnel endpoint is the known behavior of
that endpoint and the simple way of complaining when something is
broken. And people fortunately do complain when stuff is broken,
unfortunately not always with the proper details though, but I am to
blame for not finishing that program up...

> on renumber events.  Manual tunnel don't pass muster.

I guess you are one of the lucky people to get a public static IPv4
address prefix at home that never renumbers? Guess what, most of the
world does not have that luxury, they get 1 dynamic address and for
instance in Germany they get a disconnect/force-renumber every 24 hours
(according to the ISPs because of 'accounting' reasons...)

Do realize that when you have that public IPv4 address, when it changes
you are renumbering your 2002:<ipv4>::/48 prefix everywhere. Fun...
(I hope you also like asking 6to4.nro.net everytime to change your reverse)

The tunnels above all have ISP-supplied prefixes and tend to be static
(I think TSP anonymous tunnels rotate addresses, but the majority just
keeps on returning the same static allocation, in the case of SixXS you
really get a fixed address, much easier on the PoP side and we can do
whois and store it in the relevant RIR registry)

> the tunnel brokers you have to register.

I guess you also where able to anonymously sign up to your IPv4 ISP!? :)
Especially that static IPv4 address must be wonderful to get that way.

Note that Freenet6 offers 'anonymous' tunnels, thus that is just a TSP away.

Something with the amounts of abuse made us (SixXS) require that we
require valid address data. Next to that it is a RIPE requirement to
register /48 prefixes. Other Tunnelbrokers just started blocking things
like IRC and NNTP because there was too much abuse or traffic....
We kill off accounts of people when they abuse, google my name and you
will find various people who where caught in the act and are quite mad
that they can't have funny vhosts on IRC anymore and attract 500mbit
DoSses and other such nonsense which are not the goal of providing IPv6.

Also, the registration means that people can just type in their
username/password (and optionally which tunnel they want to use out of
the multiple tunnels they might have) in their CPE and the CPE then uses
TIC or TSP to fetch this configuration and set it all up, and it will
just work(tm).

As a nice example see http://www.sixxs.net/wiki/images/FritzboxHowto.jpg
and
http://www.sixxs.net/wiki/Fritz!Box_7270

Next to that knowing where the user is and more importantly their
endpoint allows one to select a proper PoP for that user close to their
endpoint causing low latency and generally high throughput.

With anycast you are just hoping that that all will work.

Greets,
 Jeroen

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 28 Jul 2011 16:27:21 -0400

> p1.  Those numbers are badly outdated.

Speaking as one of the authors of that paper: correct, the numbers are badly
outdated. You can find the more recent numbers resulting from those
measurements at:

http://www.google.com/intl/en/ipv6/statistics/

You will see that 6to4 now accounts for approximately 10% of total IPv6
traffic as measured using that methodology, and is steadily declining
(modulo seasonal variations like the French going on holiday).

---

From: "Michel Py" <[email-masked]>
Date: Thu, 28 Jul 2011 13:51:39 -0700

Lorenzo,

> Lorenzo Colitti wrote:

Thanks for the update.
Clarification: in your stats, is AS12322's traffic classified as native
or as 6to4/teredo?

Michel.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 28 Jul 2011 17:09:09 -0400

On Thu, Jul 28, 2011 at 16:51, Michel Py <[email-masked]

> Clarification: in your stats, is AS12322's traffic classified as native

As the webpage says: "The Total IPv6 graph shows IPv6 users with any type of
connectivity, while the Native IPv6 graph excludes users using 6to4 or
Teredo".

---

From: Tim Chown <[email-masked]>
Date: Thu, 28 Jul 2011 22:12:37 +0100

Hi,

I just ran a search through our Netflow logs of the most recent flows attempting to traverse our enterprise border and this showed:

2002::/16 (6to4):
Summary: total flows: 562468, total bytes: 6.2 G, total packets: 11.0 M 

2001::/32 (Teredo):
Summary: total flows: 1363887, total bytes: 4.9 G, total packets: 10.1 M

Other:
Summary: total flows: 23681562, total bytes: 483.1 G, total packets: 546.9 M

Teredo appears skewed by one host's behaviour which I'll be looking into, otherwise it's about what I'd expect with around 1% by volume being 6to4.

Tim

---

From: "Michel Py" <[email-masked]>
Date: Thu, 28 Jul 2011 14:24:18 -0700

Bad question, I apologize for the imprecision. Please allow me to
rephrase.

>> Michel Py wrote:
>> Clarification: in your stats, is AS12322's traffic
>> classified as native or as 6to4/teredo?

> Lorenzo Colitti wrote:
> As the webpage says: "The Total IPv6 graph shows IPv6
> users with any type of connectivity, while the Native
> IPv6 graph excludes users using 6to4 or Teredo".

How is 6rd traffic classified? as native or as 6to4/teredo?
I expect that the bulk of traffic from AS12322 is 6rd.

Michel.

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 29 Jul 2011 00:22:16 +0200

As a member of the G6 (http://g6.asso.fr), I'm very pleased to read this 
message and all the credits given to G6.

Without minimizing the role of the G6 association and its indivual 
members who have individually spread and participated to the deployment 
of IPv6 in their own organization (I would give credits to Renater and 
AFNIC and many others including well-known IETF participants in 
particular Francis Dupont for the first IPv6 implementation and Rémi 
Després for the first large scale deployment of IPv6 (6RD@Free), I would 
just like to mention how much we are indebted to the samurais of the 
WIDE community in Japan for having demonstrated *how to master IPv6 by 
practice.* Without this effort from Japan (KAME, USAGI, ...), IPv6 
wouldn't be where it stands today.

Regards,
Thierry Ernst.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 29 Jul 2011 07:23:20 +0900

Philip Homburg wrote:

> complete copy of the DFZ routing table...

With RFC2374, DFZ of IPv6 has at most 8192 entries.

> That still would leave a lot of issues open...

Your requirement can be fair, only with a routing protocol
supporting latency based routing for *an* address with
*multiple* paths to its destination.

There is no point to have a latency based selection of
multiple paths to the destination, only if the destination
has multiple addresses.

>     protocol to allow a host to figure out which relays are going to be used on

With anycast, you can use only a single relay. Instead, you can
compare metrics between IPv4 and IPv6 addresses of a host.

>     settings of all firewalls in the world :-)

Are you saying filtering of firewalls can be disabled by proper
address selection?

> 4) Other performance metrics, like jitter, packets loss, etc.

See 1).

> deciding when to prefer a 6to4 address over IPv4.

A problem is that there is no point to stick to IPv6 broken
so much.

But, it's not my problem.

						Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Jul 2011 11:41:54 +1200

Looking at a trace that I got from Geoff Huston a month or two ago,
there are 25486 IPv6 TCP sessions of which 10748 have a 6to4 source
address.

That's surprisingly high, showing that the answer depends greatly on
the point of observation, and explains why operators really need
to try to run a decent 6to4 relay service as long as so many
such clients are observed. Which is why disabling 6to4 in clients
has to be the priority; it's far too soon to decommission the
relays.

Regards
   Brian Carpenter

On 2011-07-29 09:12, Tim Chown wrote:
> ------------------------------------------------------------------------
>

---

From: Martin Rex <[email-masked]>
Date: Fri, 29 Jul 2011 02:28:26 +0200 (MEST)

>    of the multihomed end system.

The primary reason why the IPv4 -> IPv6 transition is so painful
is that it requires everyone one and everything to become multi-homed
and every software to perform multi-connect, even though most
devices actually just have a single interface.

It would be so much easier if hosts on the public internet could
use one single IPv6 address that contains both, the IPv6 network prefix
and the IPv4 host address, and then let the network figure out whether
the connect goes through as IPv4 or IPv6 (for IPv6 clients).

-Martin

---

From: George Michaelson <[email-masked]>
Date: Thu, 28 Jul 2011 20:28:28 -0400

you may like to look at

	http://labs.apnic.net/dns-measurement/

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 28 Jul 2011 18:55:04 -0700

> the connect goes through as IPv4 or IPv6 (for IPv6 clients).

This is largely (not entirely)  achieved with nat64 / dns64.

Cb.

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Jul 2011 22:21:11 -0400

> has to be the priority; it's far too soon to decommission the

Actually, it's why making hosts prefer IPv4 over 6to4 is the priority.   There's absolutely nothing wrong with using 6to4 if it's the best connectivity to the destination that you have.

Also,  this isn't a contest, we're on the same team, and we shouldn't be competing against one another.  The entire purpose of 6to4 is to allow people to use IPv6 before they have native IPv6 connectivity, because we recognize that the latter is in some cases very difficult to achieve end-to-end and faces numerous barriers that vary from one situation to the next.  That's why we have so many technologies for layering IPv6 over IPv4.

IOW, 6to4's purpose is to be a gateway drug for native IPv6.   And it can serve that purpose even if at any given time only 1% are using it.  The main thing is to make sure that people who do try 6to4 find it attractive enough that they want to upgrade to native IPv6.   That means not using 6to4 in cases where it will degrade performance compared to what people get already with IPv4, but it doesn't mean disabling 6to4 entirely.  It also means that DoS attacks on 6to4 are counterproductive.

Keith

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 29 Jul 2011 11:43:18 +0900

>> devices actually just have a single interface.

It was not a problem, because IPv6 was designed to be able to
handle multiple addresses properly with a single interface.

> This is largely (not entirely)  achieved with nat64 / dns64.

Assuming NAT, we don't need IPv6.

Moreover, unlike nat64, nat44 can be fully transparent end to end.

So, why do we have to be bothered by 6to4?

						Masataka Ohta

---

From: "Michel Py" <[email-masked]>
Date: Thu, 28 Jul 2011 20:41:32 -0700

> Brian E Carpenter wrote:
> Looking at a trace that I got from Geoff Huston a month or
> two ago, there are 25486 IPv6 TCP sessions of which 10748
> have a 6to4 source address. That's surprisingly high,

Not to me.

> showing that the answer depends greatly on the
> point of observation

Indeed this is the key. Validate the sample (the trace). To be
meaningful, that is. Collecting IPv6 stats somewhere close to someone
heavily involved in IPv6 deployment is meaningless. Among other things,
Tim's numbers. Tim, we have met a few times; as I recall, you are the
one who convinced me of the inevitability of IPv6 NAT. Your numbers are
meaningless; not because you don't collect them right or anything
involving your skills or competence, but because you're too close to the
problem. That's the geek syndrome.

IMHO, the only valid stats we can gather are either from a large content
provider (which is why Lorenzo's numbers are so interesting) or from a
large eyeball ISP. Cisco, Juniper, Apple, the academia, the IETF, etc
are NOT valid places to collect data.

> George Michaelson wrote:

Same remarks as above, plus I don't see there anything that separates
6rd.

Michel.

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 29 Jul 2011 00:24:00 -0400

> Same remarks as above, plus I don't see there anything that separates

6rd is global unicast... there's nothing to discriminate it from any other native range.

---

From: "Michel Py" <[email-masked]>
Date: Thu, 28 Jul 2011 22:14:15 -0700

> Joel Jaeggli wrote:

No. there is nothing in the current classification algorithm to
discriminate from any other native range. But it's not native, as it
has, among other things, the same reliance on IPv4 and the same MTU
issues than 6to4 as the core mechanism is based on 6to4 tunneling, or
encapsulation, or whatever else you want to call it.

Michel.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 29 Jul 2011 10:16:16 +0200

>> the connect goes through as IPv4 or IPv6 (for IPv6 clients).

In particular, if the remote address is encoded this way. If the host has
to chose between an IPv6 or IPv4 destination address then the protocol is
fixed.

I think that would have been a much better use of thse bits then simply
storing the ethernet address there.

But anyhow, it should be possible to do that with a destination option with is
then inspected by some middle box that makes a routing decision. But
that would require a lot of changes to retrofit it in todays operating
systems.

>This is largely (not entirely)  achieved with nat64 / dns64.

That would require the dns64 box to do destination selection. Possible, but
maybe also tricky to keep a dns resolver informed about the current state of
the network.

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 Jul 2011 06:00:59 -0400

> are NOT valid places to collect data.

I think all of the numbers are interesting, but the numbers shouldn't be separated from the conditions under which they were collected.   

It's reasonable to say "Google is now seeing X% 6to4 traffic" or "My native v6 enterprise network is seeing Y% 6to4 traffic."   What's not reasonable is to say that observations under one set of conditions are indicative of the whole network.   Even observations made at several points by a large transit carrier might not be indicative of conditions on the other side of the world.

It's also dubious to extrapolate from a few data points and call it a long term trend, because we're in a very early phase of v6 deployment (and v4 exhaustion), and there are many factors which could have a large but unpredictable influence on future use of IPv4 vs IPv6.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 Jul 2011 06:07:32 -0400

> encapsulation, or whatever else you want to call it.

Well, maybe.   One hopes that if an ISP chooses 6rd as a means to roll out v6 service to its customers, they've considered MTU issues and dealt with them as much as is feasible.   It's much easier to do that for TCP traffic than for say UDP.

All of these transition mechanisms introduce unpleasant  and undesirable corner cases.    

Keith

---

From: Ole Troan <[email-masked]>
Date: Fri, 29 Jul 2011 07:11:52 -0400

Michel,

> encapsulation, or whatever else you want to call it.

the 6rd MTU is under control of a single provider. the transport layer MTU can be set large enough to provide a 1500 byte MTU for IPv6.
I presume you are arguing that MPLS (6PE) is not native either?

cheers,
Ole

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 29 Jul 2011 08:03:36 -0400

agree but if you're trying to discriminate it by:

"This graph shows the daily unique queried reverse addresses by type."

you can't.

---

From: George Michaelson <[email-masked]>
Date: Fri, 29 Jul 2011 08:16:09 -0400

> "This graph shows the daily unique queried reverse addresses by type."

Very true Joel. I did, for a while, pattern match the 6rd prefix from Free.FR's declared ranges in RIPE whois but it was pointed out to me that dealing with one ISP like this skews things.

After all, other ISps also deploy 6rd, and Comcast do some kind of related work.

I can put in a 6rd line, if thats what people *want*

-G

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 29 Jul 2011 21:19:52 +0900

> storing the ethernet address there.

IPv6 address was (when it was SIP) and should be 8B, but extended
to be 16B to store ethernet address with wrong reasoning of RFC1715
only to make IPv6 inoperational.

At that time, it was 10B+6B, but as I pointed it out that IEEE1394
MAC is 8B long, it became 8B+8B.

> that would require a lot of changes to retrofit it in todays operating

That's no different from legacy NAT to violate the end to end
principle. For example, just as legacy NAT, transport check sum depends
on actually used address family and address. Thus, transport
check sum must be recalculated by the middle box which changes
address family.

> maybe also tricky to keep a dns resolver informed about the current state of

That's guaranteed to be impossible by the end to end argument:

   The function in question can completely and correctly be
   implemented only with the knowledge and help of the
   application standing at the end points of the communication
   system. Therefore, providing that questioned function as a
   feature of the communication system itself is not possible.

Destination address selection is the function in question and
complete and correct implementation by middle boxes is just
impossible.

The only approach for the address selection function is to do
it at the end systems using "knowledge and help" of the end
systems, which requires end systems have "knowledge" on
default free global routing tables.

						Masataka Ohta

---

From: Rémi Després <[email-masked]>
Date: Fri, 29 Jul 2011 14:52:24 +0200

Le 27 juil. 2011 à 17:29, Michel Py a écrit :
> well yourself)

> you can't deny that 6rd is 6to4-bis.

Oh, yes indeed, on can!
(Depending, of course on what you mean with 6to4-bis, but no one can be sure what you mean).

- 6to4 delivers native IPv6 prefixes to customer sites, which 6to4 doesn't.
- 6to4 has known operational problems, not 6rd.

> The difference is in
> who configures/manages it,

> not how it works;

See above.

> the 6rd code base is a
> superset of the 6to4.

Although it has been convenient to deploy 6rd starting with existing 6to4 code, one can write 6rd code that doesn't work for 6to4.

> The difference is more a matter of network design
> than core protocol.

It is a matter of clean IPv6 service, transparent to users, vs service for experts who know what they are doing.

RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 29 Jul 2011 14:57:42 +0200

>> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it clarifies the meaning of "HISTORIC" in this particular case, it does not set a precedent for any future case.

Suggestion to make the two RFC Experimental has been made, and received some support.
I haven't seen objections tho this compromise approach.
Are there some?

RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 29 Jul 2011 15:39:23 +0200

> native IPv6 if, behind the scenes, they use a tunnel broker, or 6rd?

Facts are AFAIK that:
- Tunnel brokers need host cooperation. They can't be used behind the scene by ISP's.
- 6rd can indeed be used behind the scene by ISP's, without users making the difference with native IPv6 routing in ISP networks. This has been proven on a large scale over 3.5 years. 

Regards,
RD

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 29 Jul 2011 09:51:11 -0400

> - 6rd can indeed be used behind the scene by ISP's, without users making the difference with native IPv6 routing in ISP networks. This has been proven on a large scale over 3.5 years. 

I would suspect that there's nothing that prevents an isp running it's own tunnel broker and a compliant cpe from automating that process in much the same way that 6rd in free required control over the firmware. the business case for doing so seems like an exercise for the reader.

---

From: Rémi Després <[email-masked]>
Date: Fri, 29 Jul 2011 16:12:49 +0200

Le 29 juil. 2011 à 15:51, Joel Jaeggli a écrit :

> I would suspect that there's nothing that prevents an isp running it's own tunnel broker and a compliant cpe from automating that process in much the same way that 6rd in free required control over the firmware.

Fair enough, that's a technical possibility.

> the business case for doing so seems like an exercise for the reader.

Exactly, I doubt any ISP would do that, in view of the compared simplicity of 6rd.
If that would be used, customers would have native prefixes for which they ignore that ISP-network traversal has bee tunneled.

Regards,
RD

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 Jul 2011 10:33:42 -0400

>- 6to4 has known operational problems, not 6rd.

In a sense, 6rd has all of the problems that 6to4 does.  The difference is that 6to4 is deployed independent of network operators and often without their involvement, and 6rd (when deployed) is deployed by network operators on their own networks.  So 6to4 tries to work over networks that might or might not be unsuitable for it, or even hostile to it.  By contrast, if an operator's network isn't a good fit for 6rd, they simply don't use it.   And presumably an operator choosing to use 6rd won't try to DoS it...

Again: there are valid use cases for 6to4. But almost any kind of provider managed service (except one that NATs traffic) is almost certainly better.

Keith
-- 
Sent from my Android tablet with K-9 Mail.

---

From: Rémi Després <[email-masked]>
Date: Fri, 29 Jul 2011 16:54:43 +0200

> I can put in a 6rd line, if thats what people *want*

I suppose that te proportion of native IPv6 traffic due to Free will quickly decrease as IPv6 gets really deployed by others.
(This proportion was reported to still be slightly above 50% a few months ago, but this was before the World IPv6 day and various other events.)

Yes, that would be nice to have this proportion for some time.

Thanks,
RD

---

From: "Michel Py" <[email-masked]>
Date: Fri, 29 Jul 2011 09:21:00 -0700

> Rémi Després wrote:

That is playing with words. In that case, any router that delivers native IPv6 to the hosts (by having the tunnel software on the router, not on the hosts) can be called a native solution.

This is just flat out WRONG. ANY solution that needs IPv4 to transport IPv6 is NOT native IPv6, and regardless of who states it and their great contributions, it will remain the same.

Some please stop calling things what they are not; a native IPv6 solution is one that works when IPv4 has been removed, anything else is called a transition mechanism.

Michel.

---

From: George Michaelson <[email-masked]>
Date: Fri, 29 Jul 2011 12:28:03 -0400

I have updated the graph to include 6rd, based on my understanding that the prefixes of the form 2a01:e3xx: are your 6rd space.

There is *other* FreeNet space, which appears to do things, but I sense its not part of the 6rd deployment since the numberforms in the lower /64 appear to be infrastructure assignment, not classic customer space forms.

Please let me know if I have this wrong.

You will notice that this count places Free/6rd at a far lower relative % of unique DNS than the measures of traffic and sources people discussing here. I think this bears thinking about.

-George

---

From: Rémi Després <[email-masked]>
Date: Fri, 29 Jul 2011 18:50:21 +0200

> Some please stop calling things what they are not; a native IPv6 solution is one that works when IPv4 has been removed, anything else is called a transition mechanism.

We have, it seems, a different understanding of the situation.

The distinction to be made, and which I make, is between
- native addresses vs well-known-prefix addresses (the former start with an ISP allocated prefix, the latter, e.g. those of 6to4 and Teredo, have a routing problem in the Internet backbone)
- native IPv6 routing (IPv6-only or dual stack) vs IPv4-only routing 

6rd is designed to offer native IPv6 prefixes across IPv4-only routing domains.

Regards,
RD

---

From: "Michel Py" <[email-masked]>
Date: Fri, 29 Jul 2011 11:38:16 -0700

> across IPv4-only routing domains.

There is a word for that: oxymoron. In French: oxymore.
If it stops working when IPv4 is broken, it is not native.

Michel.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 29 Jul 2011 19:16:31 +0000

6rd addresses a different problem than 6to4.

6to4 is a global solution, that relies on pretty much every native IPv6 provider deploying 6to4 relays. If these relays were really well deployed and reliable, 6to4 would allow any router with a native IPv4 address to provide IPv6 connectivity to its local users. That is, 6to4 relies on the kindness of strangers and allows uncoordinated deployments by end-users.

6rd is a local solution, that can be used by providers to easily deploy IPv6 tunnels over their existing IPv4 infrastructure. The provider controls the IPv6 prefix, which effectively defines a specific 6rd "subnet." The provider also controls the deployment of relays between the 6rd subnet and the native Internet. There is no need to rely on the kindness of strangers.

In a sense, 6rd is very similar to a tunnel broker deployment, with a key improvement and an important limitation. The key improvement is the ability for 6rd routers in the same domain to send traffic directly at each other. Local traffic stays local, does not need to be relayed by the tunnel servers or the 6rd relays. The key limitation is that 6rd assumes direct IPv4 connectivity between the participating 6rd routers, i.e. no NAT. 

6rd is a very good solution for its intended usage, rapid deployment of IPv6 by IPv4 providers. But 6rd is not a replacement for the "global, uncoordinated" 6to4 deployment. Hosts that really need this kind of uncoordinated global solution will have to rely on Teredo if they cannot use 6to4. Whether that's a good thing is clearly a matter of debate.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michel Py
Sent: Friday, July 29, 2011 11:38 AM
To: Rémi Després
Cc: [email-masked]; Keith Moore
Subject: RE: 6to4v2 (as in ripv2)? 

Michel.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 29 Jul 2011 21:42:07 +0200

In your letter dated Fri, 29 Jul 2011 11:38:16 -0700 you wrote:
>> R?mi Despr?s wrote:

Could you please elaborate why expect the internal IPv4 network of an ISP
to break while they are using it for 6rd?

It there some sort of built-in self-destruct mechanism somewhere?

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 29 Jul 2011 14:31:10 -0700

Christian,

> Behalf Of Christian Huitema
> Sent: Friday, July 29, 2011 12:17 PM
> To: Michel Py; Rémi Després
> 6to4 is a global solution, that relies on pretty much every 
> native IPv6 provider deploying 6to4 relays. If these relays 
> were really well deployed and reliable, 6to4 would allow any 
> router with a native IPv4 address to provide IPv6 
> connectivity to its local users. That is, 6to4 relies on the 
> kindness of strangers and allows uncoordinated deployments by 
> end-users.
> 
> 6rd is a local solution, that can be used by providers to 
> easily deploy IPv6 tunnels over their existing IPv4 
> infrastructure. The provider controls the IPv6 prefix, which 
> effectively defines a specific 6rd "subnet." The provider 
> also controls the deployment of relays between the 6rd subnet 
> and the native Internet. There is no need to rely on the 
> kindness of strangers.

I think this is well said. Another way of saying the
same thing is that 6to4 is an inter-site solution while
6rd is an intra-site solution when considering the
provider network as a "site". With extensions, ISATAP
can also satisfy this provider network intra-site
requirement (see draft-templin-isupdate) while enabling
the desired IPv6 services for end-user sites.

Thanks - Fred

> In a sense, 6rd is very similar to a tunnel broker 
> deployment, with a key improvement and an important 
> limitation. The key improvement is the ability for 6rd 
> routers in the same domain to send traffic directly at each 
> other. Local traffic stays local, does not need to be relayed 
> by the tunnel servers or the 6rd relays. The key limitation 
> is that 6rd assumes direct IPv4 connectivity between the 
> participating 6rd routers, i.e. no NAT. 
> 
> 6rd is a very good solution for its intended usage, rapid 
> deployment of IPv6 by IPv4 providers. But 6rd is not a 
> replacement for the "global, uncoordinated" 6to4 deployment. 
> Hosts that really need this kind of uncoordinated global 
> solution will have to rely on Teredo if they cannot use 6to4. 
> Whether that's a good thing is clearly a matter of debate.
> 
> 
> Behalf Of Michel Py
> > 6rd is designed to offer native IPv6 prefixes across 
> IPv4-only routing 
> > domains.
>

---

From: Mark Andrews <[email-masked]>
Date: Sat, 30 Jul 2011 11:06:25 +1000

>  - AYIYA + TIC => dynamic NATted addresses

I was more thinking about commonality with tunnel brokers.

6rd is not a replacement for 6to4 as it requires ISP involment or
someone to create a registry of 3rd party 6rd providers along with
associated parameters sets similar non anycast 6to4.  static proto-41
tunnel is also not a viable replacement as it doesn't handle address
reassignment at the CPE end.

---

From: "Michel Py" <[email-masked]>
Date: Fri, 29 Jul 2011 19:31:13 -0700

Ole,

> Ole Troan wrote:

That's a tough one.

What would make me say it is native is: MPLS is a L2/switching animal,
not a L3/routing one. In theory you can bind any L3 protocol such as
IPv4, IPv6, IPX, Appletalk, etc to it. So the MPLS interface is very
similar in some aspects to a real physical interface such as Ethernet or
HSSI. It reminds me of a frame-relay sub-interface in a past life.

What would make me say it is not native is: you can't remove IPv4 out of
the equation. Frame relay does not even know about which L3 protocols it
transports, while MPLS is kinda going the reverse way in the stack: it
uses L3 packets/datagrams to encapsulate and transport "L2 frames".

Here's my take:
- You can have native IPv6 over Ethernet or HDLC or Sonet or any other
L2 technology.

- Saying you have native IPv6 over fiber or copper is incorrect; you
have native IPv6 over GigE over {singlemode|multimode} (*) fiber or you
have IPv6 over Ethernet over GigE over (*) copper (or other examples)
(*) insert the appropriate 802.x standard

- I like the idea of being native requiring the IPv6 to be bound to a L2
interface. The gray area with 6PE is that the interface is logical, not
physical.

- Native IPv6 over a 6to4 or a 6RD or any kind of L3-L3 tunnel is an
oxymoron.

In other words: native IPv6 means:
a) IPv6 has to be bound to a L2 interface.
b) That interface can NOT be a tunnel interface using another L3
protocol such as IPv4.

Up for grabs:

- c1) Is it acceptable to have a structural requirement to use IPv4
(which would mean 6PE is native) or c2) is it a requirement that the
entire infrastructure (in the case of 6RD, the ISP's infrastructure)
supports IPv6 (which would mean that 6PE is not native).

Food for thought: 

- If c2) is chosen, I would consider rephrasing a) so it becomes "IPv6
has to be bound to a PHYSICAL L2 interface". Rationale: besides 6PE, are
there any other gray area candidates?

- If one is in the business of writing an draft about "what is native
IPv6", and if one of the draft's goals is to reach -cough- consensus
-cough-, one may consider "forgetting" the 6PE classification
altogether. The one part that is not open for grabs with me is
classifying 6RD as native.

Michel.

---

From: "Brzozowski, John" <[email-masked]>
Date: Sat, 30 Jul 2011 04:33:30 +0000

The Comcast 6rd trial will conclude very soon, so I do not recommend doing
anything specific for Comcast 6rd.

John

On 7/29/11 8:16 AM, "George Michaelson" <[email-masked]> wrote:

>Very true Joel. I did, for a while, pattern match the 6rd prefix from
>Free.FR's declared ranges in RIPE whois but it was pointed out to me that
>dealing with one ISP like this skews things.
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 30 Jul 2011 10:45:27 -0400

However, for what it matters here, 6rd is native after exiting from the
ISP, same as 6to4 is native after exiting from the 6to4 relay.

As we may not be able to know how "much" of the "native" IPv6 traffic is
6rd in the last mile, I think we should consider all 6rd traffic as native
for those measurements, otherwise, we will be biasing the data. Even it
may be the case of an ISP using 6rd for some part of its network, and
native for the other.

We may need to state "IPv6 native as measured, may be encapsulated in the
last mile".

Regards,
Jordi

-----Mensaje original-----
De: Michel Py <[email-masked]>
Responder a: <[email-masked]>
Fecha: Fri, 29 Jul 2011 19:31:13 -0700
Para: Ole Troan <[email-masked]>
CC: Tim Chown <[email-masked]>, IETF Discussion <[email-masked]>
Asunto: What is Native IPv6

>classifying 6RD as native.

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

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: Roger Jørgensen <[email-masked]>
Date: Sat, 30 Jul 2011 13:01:20 +0200

> classifying 6RD as native.

let me try to write all of the above in my own wording to see if I
understand what you mean...

Anything doing translation L3 <> L3 is not native, that's an easy one.
It mean IPv4 running on top of IPv6, IPv6 running on top of IPv4 is
not native.  But this easy way of seeing it only affect IPv4 and IPv6,
not all of the others.

As you said somewhere in there, anything attached to a L2 interface is
L3 and in that respect native as long as the transport from that L2
interface do not require other L3 protocols to work?
(of course it gets hairy when you involve MPLS according to Michel's
text above....)

When Jordi says:
"However, for what it matters here, 6rd is native after exiting from the
ISP, same as 6to4 is native after exiting from the 6to4 relay."

That fails the first one, it is _translated_ on L3 and is because of
that not native, even if the transportation of the packet after the
translation is 100% native as in not require another L3 protocol to
work.

I guess it all boils down to, are we talking about end to end native,
or the transportation of the L3 protocol being native?

-- 

Roger Jorgensen           |

---

From: Keith Moore <[email-masked]>
Date: Sat, 30 Jul 2011 07:45:51 -0400

> may be the case of an ISP using 6rd for some part of its network, and

good points.

I suspect that what many people are interested in is not whether the v6 traffic is "native" end-to-end, but rather, something like:

a) How much of this traffic is _managed_ end-to-end vs. how much relies on ad-hoc "kindness of strangers" e.g. RFC 3068 which we know is less reliable.
b) If certain transition mechanisms happen to be very effective/useful at getting people onto IPv6 (or not), which ones are those?  

Of course, some of these things are easier to measure than others.

Then again, others really are interested in whether the traffic is "native", since perhaps they care about applications (media streaming?) that are significantly impacted by tunneling.

Keith

---

From: Philip Homburg <[email-masked]>
Date: Sat, 30 Jul 2011 13:58:57 +0200

>classifying 6RD as native.

Why do you care so much about 'native'?

At the moment, I have 5 IPv6 connections:
1) native
2) tunnel to my ISP
3) tunnel to HE
4) tunnel to SixXS
5) 6to4

Obviously, the first one is native and the others aren't, But as user of those
links, it seems a completely arbitrary and useless distinction.
Number 5, 6to4 is obviously a problem. So that's in the 'avoid' category.
Number 3 and 4, require good access to the IPv4 Internet. At the moment
they work perfectly, but they are not future proof.
Numbers 1 and 2. In first case, ppp frames go over atm/ethernet to my ISP.
In the second case, IPv4 packets go over ppp frames over atm/ethernet to my
ISP. Yes, compared to native, the tunnel has an extra IPv4 header, but
otherwise, there is no difference. (At my ISP, native and tunneled are
terminated differently, but so far that difference is almost impossible to
notice)

So my classification would be
1) IPv6 provided by the user's ISP. (native, 6rd, tunnel by ISP)
2) IPv6 provided by a third party (tunnels by other parties)
3) IPv6 provided by unknown third parties (6to4, teredo)

1) can be made to work very well, 2) has problems, 3) is to be avoided.

---

From: "Michel Py" <[email-masked]>
Date: Sat, 30 Jul 2011 11:39:53 -0700

> JORDI PALET MARTINEZ wrote:
> However, for what it matters here, 6rd is native after
> exiting from the ISP, same as 6to4 is native after
> exiting from the 6to4 relay. As we may not be able to
> know how "much" of the "native" IPv6 traffic is 6rd in
> the last mile, I think we should consider all 6rd traffic
> as native for those measurements, otherwise, we will be
> biasing the data. Even it may be the case of an ISP using
> 6rd for some part of its network, and native for the other.
> We may need to state "IPv6 native as measured, may be
> encapsulated in the last mile".

I disagree.

6RD is not a last mile solution. With the existing levels of IPv6 traffic, an ISP would deploy a couple of 6RD relays at their main IX. In a country such as France, it means that a 6RD customer in Nice would see their IPv6 traffic being encapsulated all the way to Paris over IPv4 crossing the entire ISP's network for some 400 miles. In Spain, the really native part of the traffic would possibly start in Madrid.

Imagine 2 customers in Barcelona, who are with two different ISPs using 6RD. The 6RD relays are in Madrid for both, likely not much more than a few miles away or even possibly in the same IX (I don't know the details of IXes in Madrid). The 6RD traffic from one goes over IPv4 all the way to Madrid, then goes native for a few miles to the other ISP's 6RD relay, then back over IPv4 to Barcelona. This is not native.

On top of it, like any other tunnel solution, it stinks because the IPv6 traffic goes back all the way to Madrid while, if it was IPv4, there is a good possibility that the two ISPs are peering in Barcelona in a small colo and the traffic never leaves the town.

The obvious: the solution is, duh, native IPv6 in Barcelona and the reason ISPs are deploying 6RD is, duh, because they don't have it.

As mentioned before by Christian and other, 6RD is very similar to a tunnel broker deployment, and the number and location of relays change everything.

> Obviously, the first one is native and the others aren't,

Then we agree.

> Roger Jørgensen wrote:
> It mean IPv4 running on top of IPv6, IPv6 running on top
> of IPv4 is not native.  But this easy way of seeing it
> only affect IPv4 and IPv6, not all of the others.

I could go for that; native IPv6 mostly means "no IPv4" for the agreed scope. But I was trying to be more generic, the idea being to prevent a clever marketing droid finding a way to tunnel IPv6 over avian carriers and calling it native.

> I guess it all boils down to, are we talking about end
> to end native, or the transportation of the L3 protocol
> being native?

If I understand you correctly (I think I do) I would say it ends up being the same thing. What we want is no reliance on IPv4, what we don't want is limit implementation options.

How good is a native IPv6 network if it has to be redone when decommissioning IPv4? That's where the oxymoron is. I think a good way to see it would be: remove all IPv4 end-to-end.  If it still works, it's native IPv6. If not, it's not native.

Michel.

---

From: Philip Homburg <[email-masked]>
Date: Sat, 30 Jul 2011 21:39:22 +0200

In your letter dated Sat, 30 Jul 2011 11:39:53 -0700 you wrote:
>6RD is not a last mile solution. With the existing levels of IPv6 traffic, an 
>ISP would deploy a couple of 6RD relays at their main IX. In a country such as
> France, it means that a 6RD customer in Nice would see their IPv6 traffic bei
>ng encapsulated all the way to Paris over IPv4 crossing the entire ISP's netwo
>rk for some 400 miles. In Spain, the really native part of the traffic would p
>ossibly start in Madrid.
>
>Imagine 2 customers in Barcelona, who are with two different ISPs using 6RD. T
>he 6RD relays are in Madrid for both, likely not much more than a few miles aw
>ay or even possibly in the same IX (I don't know the details of IXes in Madrid
>). The 6RD traffic from one goes over IPv4 all the way to Madrid, then goes na
>tive for a few miles to the other ISP's 6RD relay, then back over IPv4 to Barc
>elona. This is not native.

So, 6rd is bad because it allows an ISP to deploy it in a sub-optimal way.
Wow, if that how we are going to judge protocols then we can just as well go
home.

If the existing levels of IPv6 traffic were a reason to install just one 6rd
box for an entire country then expecting that ISP to deploy native IPv6 would
be extremely unrealistic.

And even if an ISP would do that. The round trip latency between Barcelona and
Madrid is likely to be in the order of 5ms. There are DSL error correcting
settings that have much impact than that.

---

From: Mark Atwood <[email-masked]>
Date: Sun, 31 Jul 2011 13:41:47 -0700

> Moreover, unlike nat64, nat44 can be fully transparent end to end.

Some people may consider it a feature that only incumbents with power
and money can usefully call listen(), and that useful user to user
activities requires the cooperation of an intrusive 3rd party, while
mere users and upstarts can only call connect().

Some people consider that a feature.  I do not.

It is, in fact, getting really hard to avoid assuming malice on the
part of people who want to nail the world to the nat44 cross.

.. Mark Atwood

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 01 Aug 2011 14:27:35 +0900

> part of people who want to nail the world to the nat44 cross.

Isn't port forwarding over legacy nat44 enough for you?

For me, port forwarding is not enough because it lacks
end to end transparency.

For example, you can't use PORT command of your ftp
client behind legacy nat.

See draft-ohta-e2e-nat-00.txt for how nat44 can be
transparent end to end.

OTOH, nat64 can not have end to end transparency.

						Masataka Ohta