Subject: [v6ops] Reasons not to endorse NAT66/6to4 (ref draft-kuarsingh-v6ops-provider-managed-tunnel-00)

From: Rémi Després <[email-masked]>
Date: Thu, 21 Oct 2010 12:17:57 +0200

Le 20 oct. 2010 à 22:15, Victor Kuarsingh a écrit :

> The suggestion [to adopt PMT, i.e. an combination of NAT66 with 6to4 relays] was based on the fact that [6to4 is] out there.  We take what we have and try and use it for good.

There is in my understanding a far better approach:
"Rather than spending energy to partially fix some 6to4 problems, while creating new ones, deploy the "real IPv6 service" asap, and suggest to turn 6to4 off while it's not too difficult.

The "Real IPv6 service" is as follows:
- It offers reliable connectivity to all native IPv6 addresses (unlike 6to4).
- It gives ISPs control of the QoS they offer to their customers (unlike 6to4).
- It guarantees e2e network transparency between any pair of native IPv6 addresses (unlike NAT66).
- This being achieved, one doesn't care whether e2e paths are totally dual-stack, partially 6rd, partially 6a44, or whatever, provided the service is available.

A serious concern with 6to4 is that, without strict precautions that aren't taken today, it becomes an evil: it tends to disgust users from IPv6 in general (it has connectivity and QoS problems that are far beyond Grandma's understanding capability). On the other hand, the real IPv6 service keeps people satisfied.

Please, don't get me wrong:
- 6to4 has been great for early IPv6 between IPv4 clouds, and can still work perfectly between two 6to4 IPv6 addresses.
- The idea of combining 6to4 relays with NAT66's (be they stateless or stateful), is worth discussing it, and thanks for clearly raising the issue.

But the point is that, to facilitate real IPv6 deployment and willful user acceptance, NAT66/6to4 would be counterproductive.

Regards,
RD

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 21 Oct 2010 11:50:52 +0100

On 21/10/2010 11:17, Rémi Després wrote:
> But the point is that, to facilitate real IPv6 deployment and willful
> user acceptance, NAT66/6to4 would be counterproductive.

I agree with all of these points.  They're all good and valid.

However, the reality is that the CPE market is shockingly badly equipped as 
regards ipv6 support, and in many situations the provider side edge 
equipment isn't much better.  Remember, much of this equipment operates on 
a 5y lifetime basis, and even today, lots of vendors are telling people 
that their ipv6 deployment plans are only really beginning (both for CPE 
and provider edge kit).  For this reason, lack of functional ipv6 support 
on the last-mile will continue to be a problem for many years to come.

It kills me to say it - it really, really does - but in this instance, the 
overwhelming cretinousness introduced by 
draft-kuarsingh-v6ops-provider-managed-tunnel is very slightly surpassed by 
the even more overwhelmingly cretinous attitude of the cheap-as-chips 
vendors which are _still_ today designing kit which will never be ipv6 capable.

So, despite loathing this draft and every crap engineering principal it 
stands for, I am forced to admit that at this stage, we need it.

In case there's any doubt, I feel dirty to have to say this.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 21 Oct 2010 12:06:53 +0100

> stands for, I am forced to admit that at this stage, we need it.

I should add that the proposal's only mitigating virtue is that it's 
relatively easy to undo.

Nick

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 21 Oct 2010 12:16:47 +0000

Hi Remi,

I think you miss the point. Nobody here argues 6to4 was a better service
or offered this service as a primary IPv6 service. Every one agrees that
native, 6rd, etc. are far better choices. All we are saying it there are
few people (decreasing in number according to Eric) are still using 6to4
(consciously or unconsciously). To make them happier until they move to
"true" IPv6 service, an operator could offer a simple way to control the
return path. Nothing more, nothing less.

As far as I know, most operators are spending their energy to deploy IPv6.
This effort is small but does benefit a few individual and the cost is
low. 

Cheers,
Yiu

On 10/21/10 6:17 AM, "Rémi Després" <[email-masked]> wrote:

>> The suggestion [to adopt PMT, i.e. an combination of NAT66 with 6to4
>>relays] was based on the fact that [6to4 is] out there.  We take what we
>>have and try and use it for good.
>
>"Rather than spending energy to partially fix some 6to4 problems, while
>creating new ones, deploy the "real IPv6 service" asap, and suggest to
>turn 6to4 off while it's not too difficult.
>
>- This being achieved, one doesn't care whether e2e paths are totally
>dual-stack, partially 6rd, partially 6a44, or whatever, provided the
>service is available.
>
>A serious concern with 6to4 is that, without strict precautions that
>aren't taken today, it becomes an evil: it tends to disgust users from
>IPv6 in general (it has connectivity and QoS problems that are far beyond
>Grandma's understanding capability). On the other hand, the real IPv6
>service keeps people satisfied.
>
>- 6to4 has been great for early IPv6 between IPv4 clouds, and can still
>work perfectly between two 6to4 IPv6 addresses.
>- The idea of combining 6to4 relays with NAT66's (be they stateless or
>stateful), is worth discussing it, and thanks for clearly raising the
>issue.
>
>_______________________________________________
>v6ops mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/v6ops

---

From: Rémi Després <[email-masked]>
Date: Thu, 21 Oct 2010 14:45:54 +0200

> I agree with all of these points.  They're all good and valid.

Good, but reading what you say next, it seems you have significant doubts!

> However, the reality is that the CPE market is shockingly badly equipped as regards ipv6 support, and in many situations the provider side edge equipment isn't much better.

That is the point of adding clean solutions that are still missing.
(6a44, which Brian Carpenter, Sheng Jiang, and myself, are proposing is precisely that. It provides a solution for hosts behind legacy CPEs, at a cost of simple code to be added in host-OS's, and a simple add-on in one or a few ISP border devices.)  

>  Remember, much of this equipment operates on a 5y lifetime basis, and even today, lots of vendors are telling people that their ipv6 deployment plans are only really beginning (both for CPE and provider edge kit).

6rd concerns customer sites where CPEs can be updated, yes, but doesn't need PE modifications (RFC 5569 and 5969))
6a44 concerns hosts behind legacy CPEs, provided they can be upgraded, but doesn't need PE modification either.
 
>  For this reason, lack of functional ipv6 support on the last-mile will continue to be a problem for many years to come.

Not necessarily if taken with the appropriate tools (remember that it took Free.fr only 5 weeks from "no intention to support IPv6" to "It's deployed, our customers can turn it on").

> It kills me to say it - it really, really does - but in this instance, the overwhelming cretinousness introduced by draft-kuarsingh-v6ops-provider-managed-tunnel is very slightly surpassed by the even more overwhelmingly cretinous attitude of the cheap-as-chips vendors which are _still_ today designing kit which will never be ipv6 capable.
> 
> So, despite loathing this draft and every crap engineering principal it stands for,

> I am forced to admit that at this stage, we need it.

I hope you will understand you are not forced at all.

> In case there's any doubt, I feel dirty to have to say this.

You will feel a lot cleaner when you avoid to say it ;-).

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 21 Oct 2010 15:39:00 +0200

Le 21 oct. 2010 à 14:16, Lee, Yiu a écrit :

> Hi Remi,
> 
> I think you miss the point.

> Nobody here argues 6to4 was a better service
> or offered this service as a primary IPv6 service.

I never suggested that anyone expressed preference for 6to4 over native IPv6!!!
(Please don't let people believe I misunderstand so much what people say.) 
  
> Every one agrees that
> native, 6rd, etc. are far better choices.

> All we are saying it there are
> (consciously or unconsciously).

True, but if real IPv6 service is added where these people are, they will, without doing anything, stop using 6to4.
This will improve their user experience without damaging that of those that already use native IPv6.

Leaving 6to4 as is, without new investments to improve it, will damage user experiences of NEITHER 6to4 users NOR that of native IPv6 users.

> To make them happier until they move to

Let me insist that it breaks e2e transparency for native IPv6 addresses.
In particular, it doesn't open incoming connectivity in IPv6 (the IPv6 address a host sees is NOT the address to be used to reach it. IPv6 referrals become impossible!)
This is IMHO a very messy approach.

Please remember that, as it is, 6to4  AT LEAST doesn't break IPv6 e2e transparency.
IPv6 referrals and DNS AAAA's are possible today with 6to4 addresses. 

> This effort is small but does benefit a few individual and the cost is

Not sure what you mean.
If routing is IPv6-only, 6to4 isn't concerned.
If routing is duals-stack, adding 6a44 support (and encouraging host vendors to support 6a44) will expand real IPv6 availability WITHOUT BREAKING e2e transparency (i.e. IPv6 referrals and DNS AAAA's in particular).

In my understanding, hosts should better remain with only IPv4 turned on until their ISP does offer IPv6 to them, one way or another.
Any view to the contrary should IMHO be solidly argued for.

Any ISP would solve very little by supporting NAT66/6to4 combinations, and will, for sure, create significant problems.

Cheers,
RD

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 21 Oct 2010 14:04:02 +0000

Hi Remi,

>
>Any ISP would solve very little by supporting NAT66/6to4 combinations,
>and will, for sure, create significant problems.

>I still try to understand what significant problems we refer to here. I
>do agree that this only helps a small subset of users. However the cost
>to implement this is minimal. It is "almost" transparent to the users
>except those relying on 6to4 for incoming connectivity. I don't have a
>number how many people using 6to4 for incoming connections, but I guess
>the number would be small. And we will let them to opt-out. This
>methodology targets only for those who didn't even know 6to4 is on by
>default and may experience some bad experience.

Cheers,
Yiu

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 21 Oct 2010 14:08:02 +0000

Hi Remi,

>>I apologize if I mis-understood you. I saw you wrote a long paragraph to
>>explain what is "The Real IPv6 Service". I thought you tried to compare
>>this to other IPv6 technologies. Again, my apology.
>> 
>> 
>

---

From: "Scott Beuker" <[email-masked]>
Date: Thu, 21 Oct 2010 08:24:02 -0600

Remi,

> (6a44, which Brian Carpenter, Sheng Jiang, and myself, are proposing is
> precisely that. It provides a solution for hosts behind legacy CPEs, at
> a cost of simple code to be added in host-OS's, and a simple add-on in
> one or a few ISP border devices.)

Code to be added to host operating systems? So in other words, a totally unrealistic and still-born idea. You're at least 5 years too late my friend.

The time for idealism has come and gone. Drastic changes to the IPv6 transition landscape are no longer possible in a world where the customer purchases their own CPE devices and expects a decent few years use from them.

Here are the current realities:

1) 6to4 is out there
2) 6to4 provides a safety net to IPv6-only content for an IPv4-only user
3) 6to4 doesn't impede native IPv6 deployment, nor is it a substitute for it

Deal with that and move forward; or at least, please stay out of the way of those of us who are trying to. 

Promotion of your own draft is not a reason to try to impede someone else's.

> 6rd concerns customer sites where CPEs can be updated, yes, but doesn't
> need PE modifications (RFC 5569 and 5969))

So in other words, both are totally irrelevant to this discussion. Neither addresses the use case that 6to4-PMT does. Please read the draft to better understand this.

> Not necessarily if taken with the appropriate tools (remember that it
> took Free.fr only 5 weeks from "no intention to support IPv6" to "It's
> deployed, our customers can turn it on").

Free.fr has control of the customer CPE. 6to4-PMT comes to relevance in a totally different situation.

> I hope you will understand you are not forced at all.

Though it's always nice to have people ready and willing to tell other network operators, in totally different markets, cultures, and technical environments, what they must and must not do... at some point you have to step back and realize that your experiences are not necessarily universally applicable.

Thanks,
Scott

---

From: Rémi Després <[email-masked]>
Date: Thu, 21 Oct 2010 16:34:40 +0200

Le 21 oct. 2010 à 16:04, Lee, Yiu a écrit :
>> ...
>> except those relying on 6to4 for incoming connectivity.

>> I don't have a
>> the number would be small.

Maybe, but breaking what works is IMHO a bad approach to good service.
Preserving backward compatibility is in general a must, (especially if the lack of it may hurt an unknown number of users, for the sake of moderately improving service for another unknown number of users.) 

>> And we will let them to opt-out.

Ì see.
It looks like you would have made your decision in view of the low cost.
I hope you only talk about the experimental phase.

Le me make the point that changing this decision for the future won't cost much either.
And I hope you marketing guys will know about this discussion.

>> This

Again, these users should be advised not to activate IPv6 (or to deactivate IPv6 as the case may be), until you offer native IPv6 to them, one way or another. 
On the other hand, hosts that take advantage of their global IPv6 address for incoming connectivity will see their service broken when you impose NAT66 to all your 6to4 users. 
(And, if it isn't for incoming connectivity that IPv6 is used, IPv6 can be still dispensed with for still some time. No FUD to be had about any deterioration of user experience.) 

Cheers,
RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 21 Oct 2010 17:40:07 +0200

> Code to be added to host operating systems? So in other words, a totally unrealistic and still-born idea. You're at least 5 years too late my friend.

Well, my friend, I have seen many updates of host software in the last 5 year. Some of them made necessary because complex softwares badly needed fixes.

The question is, how much a particular add-on will improve user experience, in face of how expensive is it to have it. 

> The time for idealism has come and gone.

I never saw myself as an idealist.
(As a matter of fact, I believe that having invented 6rd, and convinced Free.fr that they could (in their case) deploy it rapidly, pleads for a reasonable level of pragmatism.)

> Drastic changes to the IPv6 transition landscape are no longer possible in a world where the customer purchases their own CPE devices and expects a decent few years use from them.

Please read the 6a44 draft to see that, contrary to what you seem to believe, I don't forget them.

> 2) 6to4 provides a safety net to IPv6-only content for an IPv4-only user

How many such contents do you know?
Are there vendors unwise enough to offer in IPv6-only a service destined to some IPv4-only users?

In any case, relying on a good quality safety (native IPv6) is safer than relying on one that has holes in it (6to4).
And this is even truer if some people envisage to make new holes in it (loss of e2e transparency, due to NAT66, while 6to4 still ejoys it today.)

> 3) 6to4 doesn't impede native IPv6 deployment, nor is it a substitute for it

It doesn't impede native IPv6 deployment, that's clear, but it may impede motivation to request it, people believing that it offers good-enough service.

If spoiled with NAT66 (which is the subject at hand):
- it will deteriorate 6to4 itself (IPv6 referrals impossible with 6to4 addresses)
- it will deteriorate native IPv6 (no more guarantee of e2e transparency between two native addresses (one may be an avatar of a 6to4 address, with a NAT66 in the way.   

> Deal with that and move forward;

> or at least, please stay out of the way of those of us who are trying to. 

Please feel free not to read what I write, and go your own way
Being asked to react to the new NAT66/6to4 proposal, I found it my duty to tell what I believe is important.

> Promotion of your own draft is not a reason to try to impede someone else's.

I refer to existing or proposed or solutions, even if some of them come from myself, when it is relevant to the discussion at hand.
Here again, I find it my duty.  

> So in other words, both are totally irrelevant to this discussion.

> Neither addresses the use case that 6to4-PMT does.

This was to clarify that dual-stack routing is NOT the only way to offer native IPv6 SERVICE, the best alternative to a broken 6to4.
I still believe it fits here. 
 
> Please read the draft to better understand this.

I did read the draft, and believe I do understand its implications reasonably well.
If you feel I misunderstood something, please let me know.

> Free.fr has control of the customer CPE. 6to4-PMT comes to relevance in a totally different situation.

This sentence of mine you quote was an answer to "lack of functional ipv6 support on the last-mile will continue to be a problem for many years to come.".
I still believe it is relevant.

>> I hope you will understand you are not forced at all.

This sentence of mine is more understandable if you also quote what Nick Hilliard was writing just after, namely: 
"In case there's any doubt, I feel dirty to have to say this."
I was in fact hoping that he would be relieved from "feeling dirty".
> Though it's always nice to have people ready and willing to tell other network operators, in totally different markets, cultures, and technical environments, what they must and must not do... at so…

I certainly have no intention to tell you what you must do.

RD

---

From: "Armstrong, Bill R" <[email-masked]>
Date: Thu, 21 Oct 2010 10:40:26 -0500

This is it. 

I keep hearing "just offer Native" or "deploy -[insert unreleased\un-deployed transition technology here]-" as the way to side step this proposal\problem. But I think the fundamental fact being *consistently* overlooked by the opponents to the draft is that the hands of a good deal of the operators are tied by the currently deployed(+100K's) unmanaged(not the ISPs to touch) CPE.

If the fix offered up to "just enable Native" is "simply" replace ALL the CPE that are IPv6 incapable and\or offer firmware patches for the remaining gear then we may need to have larger discussion on economic realities. Stuff costs money, new stuff doubly so. 

We need to stop looking at this as an OR to SOLVE the IPv6 problem but rather view it as an AND (as seen in bANDaid) which can help foster the adoption of IPv6.

-Bill

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Beuker
Sent: Thursday, October 21, 2010 9:24 AM
To: Rémi Després; v6ops
Subject: Re: [v6ops] Reasons not to endorse NAT66/6to4 (refdraft-kuarsingh-v6ops-provider-managed-tunnel-00)

Remi,

1) 6to4 is out there

Thanks,
Scott

E-MAIL CONFIDENTIALITY NOTICE: 

The contents of this e-mail message and 
any attachments are intended solely for the 
addressee(s) and may contain confidential 
and/or legally privileged information. If you 
are not the intended recipient of this message 
or if this message has been addressed to you 
in error, please immediately alert the sender
 by reply e-mail and then delete this message 
and any attachments. If you are not the 
intended recipient, you are notified that 
any use, dissemination, distribution, copying, 
or storage of this message or any attachment 
is strictly prohibited.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 21 Oct 2010 17:53:52 +0200

In your letter dated Thu, 21 Oct 2010 17:40:07 +0200 you wrote:
>Are there vendors unwise enough to offer in IPv6-only a service destined to=
> some IPv4-only users?

IPv6-only service is expected to be any host that is IPv6 connected and behind
a carrier-grade NAT box.

So, after IPv4 addresses run out that will be any consumer or small business
that wants to run a web server, ssh, etc. 

But the most likely source of IPv6-only will be all kinds of peer to peer
protocols that many consumers want to run, and that are quite incompatible
with carrier-grade NAT.

---

From: james woodyatt <[email-masked]>
Date: Thu, 21 Oct 2010 09:20:15 -0700

> We need to stop looking at this as an OR to SOLVE the IPv6 problem but rather view it as an AND (as seen in bANDaid) which can help foster the adoption of IPv6.

I remain unpersuaded.  I think that operators who can't bring themselves to deploy IPv6 without breaking end-to-end transparency for their subscribers should leave the business of providing IPv6 service to others.

There will still be plenty of demand for IPv4-only service for a long time to come.  It's going to be a long long time before content providers start turning off their IPv4 servers.  In other words, I see no reason to believe the statement in section 2 quoted below:

>> After IPv4 run out, IPv6 content may grow rapidly and in some cases, IPv4 may not be a connection option for some web based content providers or the remote host (IPv6 Only).

Operators still have plenty of time before they have to worry about providing subscribers with access to IPv6-only hosts on the public Internet.  I-D.ietf-behave-v6v4-framework section 2.4, "Scenario 4: an IPv4 network to the IPv6 Internet," speaks to this.

>> [...] From the transition phase discussion in Section 1.4, this scenario will probably only occur when we are well past the early stage of the "S" curve and the IPv4/IPv6 transition has already moved to the right direction. [...]

If operators have good reason to believe there is a pressing need to serve to the public IPv6 Internet to subscribers on IPv4-only first-mile links without waiting for an upgrade cycle on either residential gateways or host operating systems, then it's well past time they should have brought their concerns to the BEHAVE working group.

Maybe they should have spoke up when RFC 4966 was under discussion.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Rémi Després <[email-masked]>
Date: Thu, 21 Oct 2010 18:21:23 +0200

> If the fix offered up to "just enable Native" is "simply" replace ALL the CPE that are IPv6 incapable and\or offer firmware patches for the remaining gear then we may need to have larger discussion…

It is NOT "simply replace ALL the CPE that are IPv6 incapable".
Brian Carpenter, Sheng Jiang, and myself, propose a simple solution for native IPv6 across NAT44 CPEs i(draft-despres-softwire-6a44-00).  
Its limitation (strong at this point, but which may evolve as the specification gets well understood) is that it depends on an update in host software.
Host software upgrades appear to be unavoidable to achieve simple, efficient, and reliable, native IPv6 across legacy CPEs.

> We need to stop looking at this as an OR to SOLVE the IPv6 problem but rather view it as an AND (as seen in bANDaid) which can help foster the adoption of IPv6.

We all agree, I believe, that one size doesn't fit all.

The specific danger of NAT66/6to4 is that, being easy to implement and to operate, there is a temptation to deploy it.
But, if deployed, it breaks things that worked before.
In particular it breaks the possibility to advertise one's own 6to4 address and to be reachable at this address by IPv6 hosts that have access to a 6to4 relay.
(Besides, but this is less important, the amount of user experience that could be improved by a NAT66/6to4 deployment is unclear.) 

Regards, 
RD

---

From: Fernando Gont <[email-masked]>
Date: Thu, 21 Oct 2010 14:04:21 -0300

On 21/10/2010 07:17 a.m., Rémi Després wrote:

> aren't taken today, it becomes an evil: it tends to disgust users
> from IPv6 in general (it has connectivity and QoS problems that are
> far beyond Grandma's understanding capability). On the other hand,
> the real IPv6 service keeps people satisfied.

I don't think people care about which version of IP is servicing them.
If Grandma cannot understand the problems you're referring to, the
distinction between IPv4 and IPv6 is probably out of her scope, too.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 21 Oct 2010 10:10:58 -0700

> Operators still have plenty of time before they have to worry about providing subscribers with access to IPv6-only hosts on the public Internet.  I-D.ietf-behave-v6v4-framework section 2.4, "Scenar…

I strongly disagree with this, especially since i have firm plans of
launching IPv6-only handsets + NAT64 next year (2011). In fact i have
it running in beta today with ~200 paying subscribers.  This is the
reality of smartly not investing more in IPv4, having been reject for
IPv4 space, and running on empty (aka bogons) for several years now.
And, the mobile and cloud network edge keeps growing quickly.

The moral of the story is that access networks will be IPv4-only,
IPv6-only, or dual stack. Content providers need to choose who they
want to see their content, this is usually results in when they go
dual-stack, not if.  I don't believe that my customers care about the
difference on many types of handsets between IPv4 + NAT44 and IPv6 +
NAT64, just like they don't care that i give them bogons today.
Content providers may tell the difference between IPv6 and IPv4 on the
UE, and many have made it clear they prefer IPv6 since it takes the
CGN out of the path when they (content) do offer IPv6 services.

Side note, it is also cheaper and more robust to run IPv6, since major
content players like Google and Facebook will no longer need NAT44 in
my network, their native IPv6 by-passes the NAT64.

Cameron

---

From: "Armstrong, Bill R" <[email-masked]>
Date: Thu, 21 Oct 2010 12:20:36 -0500

So we all agree that software upgrades are the key. I'm not NOT going to support\deploy 6rd 6a44 or DS-lite because of PMT rather due to the fact that they don't exist yet, its new stuff, once software has been written and has been folded into the dev cycles of all the major hardware\software vendors then we have yet another tool that can be used to work toward ubiquitous IPv6. So while we wait, 6to4 is there NOW and what PMT adds from a functionality perspective(I think) outweighs the potential breakage concerns. 

-Bill

-----Original Message-----
From: Rémi Després [mailto:[email-masked]] 
Sent: Thursday, October 21, 2010 11:21 AM
To: Armstrong, Bill R
Cc: Scott Beuker; v6ops
Subject: Re: [v6ops] Reasons not to endorse NAT66/6to4 (refdraft-kuarsingh-v6ops-provider-managed-tunnel-00)

Regards, 
RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 21 Oct 2010 19:29:22 +0200

> I don't think people care about which version of IP is servicing them.

Absolutely right.
Robustness and plug-and-play are a must for ordinary people.
Solutions that work only in 95% of cases, and that you have to configure are the worse of all. 

> distinction between IPv4 and IPv6 is probably out of her scope, too.

Absolutely.
Her host, should by default work in IPv6  only if it a native IPv6 address.
A host that accepts by default to work with 6to4 or Teredo isn't a good approach for Grandma.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 21 Oct 2010 19:34:48 +0200

Le 21 oct. 2010 à 19:20, Armstrong, Bill R a écrit :

> So we all agree that software upgrades are the key. I'm not NOT going to support\deploy 6rd 6a44 or DS-lite because of PMT rather due to the fact that they don't exist yet, its new stuff, once software has been written and has been folded into the dev cycles of all the major hardware\software vendors then we have yet another tool that can be used to work toward ubiquitous IPv6.

> So while we wait, 6to4 is there NOW

Yes, some people use it 6to4 its limits. 
Breaking 6to4's e2e transparency is likely to create more problems than it is expected to solve.
 
> and what PMT adds from a functionality perspective(I think) outweighs the potential breakage concerns.

Very different view here.
At least people won't be able to say they weren't informed.

RD

---

From: Fernando Gont <[email-masked]>
Date: Thu, 21 Oct 2010 14:56:58 -0300

Hi, Remi,

> A host that accepts by default to work with 6to4 or Teredo isn't a good approach for Grandma.

Are you arguing that e.g. Teredo and 6to4 should be disabled by default,
or rather that IPv4 should be preferred over IPv6 when the IPv6
connectivity is provided by Teredo/6to4?

Thanks,

---

From: james woodyatt <[email-masked]>
Date: Thu, 21 Oct 2010 11:11:14 -0700

everyone--

I'm about to start advocating seriously that the Darwin IPv6 stop autoconfiguring interface addresses with the 2002::/16 prefix even when the Prefix Information Option has the A=1 bit set.  If this draft progresses or operators start seriously looking like they're going to deploy 6to4-PMT, then I'm pretty sure there won't be any alternative.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 21 Oct 2010 11:33:53 -0700

Some other limiting factors to consider wrt the proposal:

- strict provider-aggregated instead of provider-independent
- mobility, multihoming, traffic engineering not well supported
- only addresses IPv6-in-IPv4 (not other protocol combinations)
- tunnel MTU uncertainties

Fred
[email-masked]

---

From: Erik Kline <[email-masked]>
Date: Thu, 21 Oct 2010 13:36:25 -0700

On 21 October 2010 11:11, james woodyatt <[email-masked]> wrote:

> everyone--
>
> I'm about to start advocating seriously that the Darwin IPv6 stop
> autoconfiguring interface addresses with the 2002::/16 prefix even when the
> Prefix Information Option has the A=1 bit set.  If this draft progresses or
> operators start seriously looking like they're going to deploy 6to4-PMT,
> then I'm pretty sure there won't be any alternative.

At first blush, this sounds like a reasonable idea to me regardless.  Or at
least that may be reasonable default behavior and those who want the feature
can check the "take my life into my own hands" check box.  =)

---

From: Rémi Després <[email-masked]>
Date: Fri, 22 Oct 2010 09:21:41 +0200

> Are you arguing that e.g. Teredo and 6to4 should be disabled by default,

Yes.

> connectivity is provided by Teredo/6to4?

No.

The idea is that Teredo and 6to4, which are useful in some identified scenarios but have some lose ends in some others, should be reserved to users that know what they do.

Typically, users that don't know how to configure port forwarding in their CPEs, only use applications that do work across NAT444.
Avoiding to enable non-native IPv6 (6to4 or Teredo) can protect against some connectivity hazards while maintaining their normal user experience.  
Now, when native IPv6 addresses are made available (whatever the tool used), they should, without even noticing it, use IPv6 instead of IPv4 to reach dual-stack servers. As a result, their consumption of shared IPv4 addresses CGNs will automatically decrease, for the good of all.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 22 Oct 2010 10:38:21 +0200

> I'm about to start advocating seriously that the Darwin IPv6 stop autoconfiguring interface addresses with the 2002::/16 prefix even when the Prefix Information Option has the A=1 bit set.  If this…

Full agreement.
By adding NAT66 to 6to4, those who believe that they will improve 6to4 By adding NAT66 to it, may very well just kill it.

RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 22 Oct 2010 10:45:15 +0200

Le 21 oct. 2010 à 22:36, Erik Kline a écrit :

> At first blush, this sounds like a reasonable idea to me regardless.  Or at least that may be reasonable default behavior and those who want the feature can check the "take my life into my own hands" check box.

An intermediate stand (as long as 6to4-PMT doesn't come to break 6to4), is that router CPEs do propagate 6to4 prefixes, but that, *by default* hosts have IPv6 enabled ONLY IF they have native IPv6 addresses.

>  =)

---

From: "Scott Beuker" <[email-masked]>
Date: Fri, 22 Oct 2010 08:35:37 -0600

> The idea is that Teredo and 6to4, which are useful in some identified
> scenarios but have some lose ends in some others, should be reserved to
> users that know what they do.

Exactly the opposite, in my opinion. If you ask the creators of Teredo and 6to4, I think they'll tell you it's intended to catch the users who know nothing of IPv6, and allow the rest of us who do to proceed with the transition to IPv6, without having them hold us back.

Regardless, as it is this is how it can be leveraged, and it will be for the best of the IPv6 transition effort if it is.

- Scott

---

From: Rémi Després <[email-masked]>
Date: Fri, 22 Oct 2010 18:01:30 +0200

Le 22 oct. 2010 à 16:35, Scott Beuker a écrit :

> Exactly the opposite, in my opinion.

Note that the RFC on Teredo (RFC 4380) says "Teredo is designed to provide an "IPv6 access of last resort" to  nodes that need IPv6 connectivity but cannot use any of the other IPv6 transition schemes."
Today, the ordinary user doesn't NEED IPv6 connectivity. 
In my understanding, Teredo is appropriate for those who know enough about IPv6 to determine that they NEED it, but oNLY for these.

> If you ask the creators of Teredo and 6to4, I think they'll tell you it's intended to catch the users who know nothing of IPv6, and allow the rest of us who do to proceed with the transition to IPv6, without having them hold us back.

I add a Direct copy to Brian Carpenter, the creator of 6to4.

It's also worth taking in consideration what James Woodyatt, a major promoter of 6to4 in Apple products, has written about 6to4-PMT: 
"I'm about to start advocating seriously that the Darwin IPv6 stop autoconfiguring interface addresses with the 2002::/16 prefix even when the Prefix Information Option has the A=1 bit set.  If this draft progresses or operators start seriously looking like they're going to deploy 6to4-PMT, then I'm pretty sure there won't be any alternative."

Regards,
RD

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Oct 2010 09:15:38 +1300

> Exactly the opposite, in my opinion. If you ask the creators of Teredo and 6to4, I think they'll tell you it's intended to catch the users who know nothing of IPv6, and allow the rest of us who do…

I don't know what Christian would say about Teredo, but 6to4 as defined
in RFC 3056 was entirely aimed at consenting adults: a site that wanted
IPv6 access but whose ISP did not provide it, and a remote ISP
that provided IPv6 access and was willing to operate a unicast 6to4
relay.

Unfortunately, RFC 3068 subverted this by endorsing host-based
instead of router-based 6to4, and defining an anycast address for
6to4 relays. That has seen a lot of usage, but does create the
return path problem.

On 2010-10-23 08:04, Gert Doering wrote:

> One approach to rework 3056 would be to completely deprecate the 
> 6to4-with-anycast model.  

That is to say, deprecate RFC 3068 and revert to the pure RFC 3056 model.

Good idea. Could you push my toothpaste back into the tube, too, please ;-)

     Brian

---

From: "Scott Beuker" <[email-masked]>
Date: Fri, 22 Oct 2010 14:40:07 -0600

> Note that the RFC on Teredo (RFC 4380) says "Teredo is designed to
> provide an "IPv6 access of last resort" to  nodes that need IPv6
> connectivity but cannot use any of the other IPv6 transition schemes."
> In my understanding, Teredo is appropriate for those who know enough
> about IPv6 to determine that they NEED it, but oNLY for these.

Yes, *today* that is true. But by that same logic, IPv6 isn't necessary at all *today*. This isn't about today. This is about a year or two from now. This is about the point in time when IPv6 is necessary, and yet some people don't have it.

- Scott

---

From: Gert Doering <[email-masked]>
Date: Sat, 23 Oct 2010 11:20:30 +0200

Hi,

> That is to say, deprecate RFC 3068 and revert to the pure RFC 3056 model.

Well, yes.  Sorry for mixing these RFCs.

> Good idea. Could you push my toothpaste back into the tube, too, please ;-)

Well, it's not like we haven't done this before.  A6/bitstring depreciation
comes to mind...

Gert Doering
        -- NetMaster
-- 
did you enable IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Victor Kuarsingh <[email-masked]>
Date: Sat, 23 Oct 2010 11:55:09 -0400

Gert,

Just a question..

RFC3068 (with RFC3056) works and is deployed widely in production networks
(via OSs, Gateways and other equipment).

Why would we depreciate something that works before all the viable
alternatives (6RD, Native IPv6 and new things like 6a44) are still not out
there in mass?  Why reduce that IPv6 glue space?

I would say we wait until those newer technologies are considered deployed
and then consider depreciating something that actually works and is out
there.  It seems premature in my mind, given that the only issue we see is
the the performance related to return path (with was what we were trying to
help correct).  Other then this... It work.

Plus, depreciating it would take time since it hard to force customers to
upgrade OSs (although this has become automated in most OSs) and consumer
equipment (many customers do not upgrade past store rev firmware).

Trust me, when the other technologies are out there, and viable in mass,
providers will leverage them.

On the point of

" If there's real interest to reach those servers, the clients will find
a way to get IPv6 - but it's unlikely that we'll see IPv6-only servers
any time soon."

I do agree that IPv6-only servers are less likely soon (but still a threat
after IPv4 runout, but IPv6-only endpoints is possible (i.e. Other host).
AS to customers "finding a way to get IPv6", once again, I don't even think
most know what IPv6 is - much less seek it out.  They would just detect
"brokenness" should something be IPv6-only and have access to IPv4-only.

My analogy to Internet usage for most is like "gas in the car".  Most people
put gas in the card, turn the key and press the accelerator/break.  All the
rest "just works". Our mission (as operators) will be to make things "just
work".

Just a thought.

Regards,

Victor

---

From: Gert Doering <[email-masked]>
Date: Sat, 23 Oct 2010 18:44:47 +0200

Hi,

> (via OSs, Gateways and other equipment).

Well, whether "6to4+anycast relay" (RFC 3068) "works" seems to be a matter 
of interpretation - if it works, why would we need 6to4-PMT?

Obviously, it does not work sufficiently well - and since the envisioned
need ("connect to ipv6-only content") isn't there (there is no ipv6-only
content), but it does harm, it seems to be more useful to deprecate it
completely, instead of investing more work into something that is not
useful.

[..]
> rest "just works". Our mission (as operators) will be to make things "just

Yes, and to me, "fiddling with 6to4 anycast, wasting more effort and
breaking one of the most important bits of IPv6, end-to-end transparency
between IPv6-speaking nodes, in process" is not a good way to make things
"just work".

If "gas in the car" people notice that certain thing are problematic, like
"leaded gas", they stop using them.

Gert Doering
        -- NetMaster

---

From: Rémi Després <[email-masked]>
Date: Mon, 25 Oct 2010 09:35:29 +0200

Le 23 oct. 2010 à 17:55, Victor Kuarsingh a écrit :
> rest "just works".

> Our mission (as operators) will be to make things "just
> work".

Agreed, what is needed is what "just works".

Now:
* Native IPv6 "just works"
 1. guaranteed e2e address transparency (OK for peer-to-peer)
 2. guaranteed connectivity
 3. ISP control of customer QoS
* 6to4 between two 6to4 addresses (without 6o4 relays) "just works":
 1. guaranteed e2e address transparency
 2. guaranteed connectivity
 3. ISP control of customer QoS (that of IPv4)
* 6to4 between a 6to4 address and a native-IPv6 address (with 2 6to4 relays) "doesn't just work":
 1. (e2e address transparency still available)
 2. guaranteed connectivity is LOST
 3. ISP control of customer QoS is LOST

If SOME ISPs would deploy 6to4-PMT, i.e. add NAT66's to 6to4 relays, 6to4 would EVEN LESS "just work":
- For 6to4 customers of 6to4-PMT ISPs:
 1. e2e address transparency is LOST (peer-to-peer in Ipv6 is broken)
 2. guaranteed connectivity is still LOST  (depends on whether remote native-IPv6 hosts access 6to4 relays)
 3. ISP control of customer QoS is still LOST (if remote native-IPv6 hosts have access to 6to4 relays, it depends on which ones) 
- For native IPv6 customers
 1. guaranteed e2e address transparency is LOST (remote native IPv6 addresses may now be translated on their way)
 2. guaranteed connectivity with 6to4 addresses is still LOST (not all 6to4 addresses are 6to4-PMT addresses)
 3. ISP control of customer QoS is still LOST (not all 6to4 addresses are 6to4-PMT addresses)
- For 6to4 customers of ISPs that haven't 6to4-PMT:
 1. e2e address transparency is LOST (they may be talking to 6to4-PMT customers)
 2. guaranteed connectivity is still LOST (they may have no access to a 6to4 relay)
 3. ISP control of customer QoS is LOST (if they access some 6to4 relays, it depends on which ones)

6to4-PMT is simple, a quality, but, by combining two mechanisms that already create more problems than they solve (6to4 relays and NAT66), it can only lead to poor user experience in IPv6.

The technical content of the above can be challenged if one finds that is has mistakes.
But if it is right, the conclusion is that, to only keep solutions that "just work", using the 6to4 anycast address in 6to4 customers should be turned off, at least by default, and that where 6to4 relays are still in use, no NAT66 of any form should be added to them. 

> equipment (many customers do not upgrade past store rev firmware).

Deprecating a spec only means "if you have the choice, no longer do it".
In my understanding, deprecating 6to4-anycast in customer devices doesn't mean that 6to4 relays that exist today should be dismantled.
As long as operators of these relays don't offer native IPv6, and see that they still have users, they are perfectly entitled to maintain these relays for these users.

To conclude, the proposal is that IETF:
- deprecates the use of the 6to4-relay anycast address in 6to4 routers 
- explains why associating NAT66's with 6to4 relays should be avoided
This will contribute to make IPv6 something that "just works". 

Regards,
RD

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 27 Oct 2010 22:14:45 -0400

Remi,

I do appreciate the points from the group.  I agree, IPv6 native =
good/best.  I also agree, where I cannot have Native IPv6, we will provide a
more managed solution (like 6RD).  Don't get me wrong, I will push for IPv6
with all my might and effort.

But unfortunately, neither of these options help operators where there are
"unmanaged" devices which are not yet upgraded to support such technologies.
Believe it or not, many persons do not ever upgrade their firmware in their
home gateways)

Operators need an option to help customers who have not yet replaced
equipment which has a "current set" of features (and as noted, this often
includes 6to4 default operation).  PMT offered a way of doing this such that
the customer would get a level of service by default based on current
hardware.

The intent is not to use PMT as a "good IPv6" option, but rather as a "last
resort IPv6 option" if needed.  I cannot stress enough that this is not
intended to challenge, distract or replace real IPv6 deployments.  But, many
operators have commented on this list that the reality in our networks is
that we cannot control all our CPE endpoints, and replacing them is many
times out of our control.

We will continue to persuade users to upgrade/replace their equipment, but
experience has shown us that this takes time, and often times unsuccessful
(refusal, unwillingness etc)

It appears that that a number of commenter's in this list would rather us
(operators) not address this segment of the population, and just "hope" that
IPv4 only will work for them (again, I understand the risk of IPv6 only
endpoints is low, but possible).

I offer this question to the list, what "option" is available for the
"non-upgraded" and "IPv4 only" endpoints? I will say that quoting a new
technology like 6RD and native IPv6 are not options for the use case we have
presented.  Ignoring these customers is also not an option.  We are in the
business of helping customers even if they don't help themselves (to the
extent possible).

Would the group agree with this statement "we would rather provide no IPv6
at all rather then IPv6 based on 6to4-PMT"?

Again, our goal (in order of preference)
1. Provide IPv6 Native
2. Provided Managed Tunnel IPv6 (like 6RD)
3. If uncontrolled/un-upgraded CPE - provide last resort option (which PMT
was one of our suggestions)
4. Do nothing and hope for the best (I hate this one the most)

Constructive options welcome.  I am not trying to be difficult or
belligerent, but rather looking for solutions to problems.

Regards,

Victor

On 25/10/10 3:35 AM, "Rémi Després" <[email-masked]> wrote:

>  3. ISP control of customer QoS is still LOST (if remote native-IPv6 hosts
> have access to 6to4 relays, it depends on which ones)
> 6to4-PMT is simple, a quality, but, by combining two mechanisms that already
> create more problems than they solve (6to4 relays and NAT66), it can only lead
> to poor user experience in IPv6.
> 
> But if it is right, the conclusion is that, to only keep solutions that "just
> work", using the 6to4 anycast address in 6to4 customers should be turned off,
> at least by default, and that where 6to4 relays are still in use, no NAT66 of
> any form should be added to them.
> 
> 
> In my understanding, deprecating 6to4-anycast in customer devices doesn't mean
> that 6to4 relays that exist today should be dismantled.
> As long as operators of these relays don't offer native IPv6, and see that
> they still have users, they are perfectly entitled to maintain these relays
> for these users.
> 
>

---

From: Randy Bush <[email-masked]>
Date: Thu, 28 Oct 2010 11:39:15 +0900

> The intent is not to use PMT as a "good IPv6" option, but rather as a
> "last resort IPv6 option" if needed.

none, i repeat _none_, of the non-native/dual deployments, 6to4, pmt,
6rd, teredo, ... are good ipv6 options.  they are hacks to get around
choosing not to deploy real ipv6.

the perceived quality of the various non-good hacks varies mainly by
environment and implementation.  but they are all hacks to get around
not deploying ipv6.

> many operators have commented on this list that the reality in our
> networks is that we cannot control all our CPE endpoints, and
> replacing them is many times out of our control.

i used the word "chooising" above carefully.  it is all a trade-off.
replacing cpe may be quite expensive, but one might choose to do it and
one might not.  i would not belabor this seemingly trivial point except
that it places an upper bound on my sympathy for non-depolyment and for
how grotty a hack i am willing to tolerate.

> "non-upgraded" and "IPv4 only" endpoints? I will say that quoting a
> new technology like 6RD and native IPv6 are not options for the use
> case we have presented.  Ignoring these customers is also not an
> option.  We are in the business of helping customers even if they
> don't help themselves (to the extent possible).

and what does this have to do with ipv6 deployment and operation?

randy

---

From: james woodyatt <[email-masked]>
Date: Wed, 27 Oct 2010 20:51:33 -0700

On Oct 27, 2010, at 19:14, Victor Kuarsingh wrote:
> 
> I offer this question to the list, what "option" is available for the "non-upgraded" and "IPv4 only" endpoints?

As mentioned in I-D.ietf-behave-v6v4-framework, the only remaining option available to you is RFC 2766.  It's been moved to historic status [RFC 4966] because it has its problems, but it would be better than 6to4-PMT, because it would not introduce NAT66 into otherwise apparently IPv6-native paths between the IPv6 subscriber network and the public IPv6 Internet.

> Would the group agree with this statement "we would rather provide no IPv6 at all rather then IPv6 based on 6to4-PMT"?

I would rather see NAT-PT deployed than 6to4-PMT.  I strongly believe that each and every deployment of 6to4-PMT will separately detract from the welfare of everyone in the Internet community.  If it's widely deployed, it would be an epic disaster for the IPv6 transition overall.

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 27 Oct 2010 23:55:53 -0400

> environment and implementation.  but they are all hacks to get around

Agreed, PMT is yet another hack. I cannot argue that.  But a hack based on
some existing (deployed) functionality (I am not waiting for the mass market
to filter in this behavior based on hardware turnover and/or firmware
updates [considering many don't do this anyway])

> how grotty a hack i am willing to tolerate.
I think we will need to agree to disagree here.  I think suggesting that
operators are not choosing to deploy IPv6 by not supplying IPv6 gateways at
mass (where the normal case was customers bring their own gateways) is not a
true reflection of what is feasible in many cases.

I am not saying that some operations are not being lazy, but that is not my
case.  We are working hard at it.

> and what does this have to do with ipv6 deployment and operation?
I would suggest that PMT, although another hack, is attempting to provide
some level of IPv6 connectivity, so it fits here.  6to4, although over IPv4,
is still IPv6 over the top.

Victor

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 28 Oct 2010 00:10:30 -0400

James,

>> "non-upgraded" and "IPv4 only" endpoints?
> 
> As mentioned in I-D.ietf-behave-v6v4-framework, the only remaining option
> available to you is RFC 2766.  It's been moved to historic status [RFC 4966]
> because it has its problems, but it would be better than 6to4-PMT, because it
> would not introduce NAT66 into otherwise apparently IPv6-native paths between
> the IPv6 subscriber network and the public IPv6 Internet.

I was under the impression that part of the list of drawbacks to RFC2766 was
related to the IPv4 Network -> IPv6 Internet type flows (managing state, etc
- but I will re-read 4966).

Are you suggesting translating from IPv4 to IPv6 is better then IPv6 to
IPv6? (PT66/NAT66)  Both remove e2e transparency (so no gain here either
way).  Maybe I am off here, but I would have thought that in-family
translation beats cross-family translation.

> I would rather see NAT-PT deployed than 6to4-PMT.  I strongly believe that
> each and every deployment of 6to4-PMT will separately detract from the welfare
> of everyone in the Internet community.  If it's widely deployed, it would be
> an epic disaster for the IPv6 transition overall.

"epic disaster" seems a bit harsh, perhaps testing and characterization
would better defined how good or bad this is.

I think one of your concerns here is that the use of PMT would potentially
inhibit IPv6 deployment if operators do this in place of working on IPv6,
but this is not the intent.  I think you give this option too much credit -
I don't think this would stop IPv6 deployments (opinion stated). I think it
would be used for what it's intended - last resort until operators can
influence the right change at the customer CPE/host.

If I got this right, it's more about possible actions of operations rather
then actually characteristics of the option (which as Remi noted have
fallbacks - which are duly noted and would require due diligence to
characterize)

Regards,

Victor

---

From: Rémi Després <[email-masked]>
Date: Thu, 28 Oct 2010 10:10:01 +0200

Le 28 oct. 2010 à 04:14, Victor Kuarsingh a écrit :

> more managed solution (like 6RD).

Note that a useful distinction here is between native-IPv6 ROUTING and native-IPv6 ADDRESSES.
6rd does provide native-IPv6 ADDRESSES to customers (unlike 5to4 and Teredo).
This is because users can't even detect that their IPv6 packets traverse some IPv4-only routing domain via tunnels.  

> Believe it or not, many persons do not ever upgrade their firmware in their

Not only I do believe it, but its is precisely why, with Brian and Sheng, we propose 6a44 (www.ietf.org/id/draft-despres-softwire-6a44-01).
- It offers to native-IPv6 addresses to 6a44-capable hosts that are behind NAT44-CPEs.
- It is plug and play.
- Traffic between two hosts behind the same NAT44-CPE remains within their site.
- It can work even in sites that only get private IPv4 addresses of RFC 1918. 
  
> includes 6to4 default operation).

That's why current 6to4 users shouldn't lose the ability to be reached at their 6to4 address, including by hosts that have native-Ipv6 addresses and routes via 6to4 relays.
Adding a NAT66 to 6to4 relays breaks this ability.
This technical reality MUST NOT be ignored.  

> ... But, many

Indeed, and 6a44 has been designed for them.
(We have to face that many existing CPEs don't support 6to4.) 

> IPv4 only will work for them

I noticed that too, and believe they don't understand the situation.

All my personal efforts, from 6rd to 6a44, and including opposition to endorsing the NAT66-6to4 combination, are to promote good user experience with IPv6.

> "non-upgraded" and "IPv4 only" endpoints?

If neither the host not the CPE is upgraded, the host is left with IPv4-only and NAT44's, with their limitations.

> at all rather then IPv6 based on 6to4-PMT"?

That's a strange question because adding NAT66 to 6to4 doesn't increase the number of IPv6 addresses offered to customers.
It just modifies what a host can do with its IPv6 address:
(a) It ensures a return path for connections from 6to4 to native IPv6 
(b) It breaks the possibility to be reachable at this IPv6 address.

It has to be faced that (b) would be a terrible step backward for 6to4 (and for IPv6 in general).
(See what James Woodyatt, among the well-known best friends of 6to4, says about it.)  

> Constructive options welcome.  

6a44 is a constructive option.
(Reactions to the proposal are most welcome.)

Destructive proposals are legitimate only as long as it isn't clear that they are destructive.
And it happens (unfortunately I agree) that adding NAT66 to 6to4 IS destructive 

Regards,
RD

Red

> I am not trying to be difficult or

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Thu, 28 Oct 2010 10:40:47 +0200

In general, I prefer a managed service... I mostlikely have a SLA with
the provider and pay 
for the service, so I expect acceptable quality in return.

If Billy-Bob, the couch potato can by that service access Internet
resources otherwise not available, then Billy-Bob is happy.
(because Billy-Bob does not care what is happening under the curtains...
neither for v4 and neither for v6 magic)

@James, I assume you meant NAT64 and not NAT-PT?

G/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Victor Kuarsingh
Sent: Thursday, October 28, 2010 6:11 AM
To: james woodyatt
Cc: IPv6 Operations
Subject: Re: [v6ops] Reasons not to endorse NAT66/6to4

James,

> the IPv6 subscriber network and the public IPv6 Internet.

I was under the impression that part of the list of drawbacks to RFC2766
was
related to the IPv4 Network -> IPv6 Internet type flows (managing state,
etc
- but I will re-read 4966).

> 
>> Would the group agree with this statement "we would rather provide no
IPv6 at
>> all rather then IPv6 based on 6to4-PMT"?
> 

I think one of your concerns here is that the use of PMT would
potentially
inhibit IPv6 deployment if operators do this in place of working on
IPv6,
but this is not the intent.  I think you give this option too much
credit -
I don't think this would stop IPv6 deployments (opinion stated). I think
it
would be used for what it's intended - last resort until operators can
influence the right change at the customer CPE/host.

If I got this right, it's more about possible actions of operations
rather
then actually characteristics of the option (which as Remi noted have
fallbacks - which are duly noted and would require due diligence to
characterize)

Regards,

Victor

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 28 Oct 2010 09:53:05 +0100

My take on 6to4-PMT:
- not nice. a hack. (not our first hack, will not be the last one,  not 
the worst one, but you may have a different opinion)
- pretty short time lifetime (well, things live around much longer than 
usually thought of, but anyway: in the grand scheme of things, should be 
"short")
- I understand (and agree to some level) the reasons for deploying such 
schemes.
- if this is being implemented and deployed, then it would be good to be 
documented somewhere in an RFC.
- I have only one concern which has been raised before in one way or 
another: what is the real footprint of 6to4-enabled devices in broadband 
networks now and soon that is enough big to justify working on this scheme?
- So I suggest the following if-then-else:
  if the 6to4 footprint is enough "high", then work within IETF wg 
(behave?) to make an RFC, else get reviewers in this community and 
elsewhere to comment/improve the spec and send it to RFC editor for 
individual submission, experimental or informational track.

Marc.
-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca

---

From: Rémi Després <[email-masked]>
Date: Thu, 28 Oct 2010 14:21:17 +0200

Le 28 oct. 2010 à 10:53, Marc Blanchet a écrit :

> My take on 6to4-PMT:
> - not nice. a hack. (not our first hack, will not be the last one,  not the worst one, but you may have a different opinion)

Couldn't you join James and myself to understand that 6t4-PMT does more harm to 6to4, and to IPv6 in general, than it improves it?

Once more:
6to4 users have today the ability to be reached at their 6to4 addresses, not only from other 6to4 addresses, but also from  native-Ipv6 addresses that have routes to any 6to4 relay.
Adding a NAT66 to a 6to4 relays breaks this ability for all users that depend on this relay.
This technical reality is destructive, and MUST NOT be ignored.

Putting  6rd in the same undifferentiated category as 6to4-PMT, although 6rd permitted the largest deployment of native IPv6 addresses so far, with happy ISPs and happy customers, and without operational loose ends where it is applicable, doesn't contribute, IMHO, to promote availability of good quality IPv6. 

Regards,
RD

---

From: [email-masked]
Date: Thu, 28 Oct 2010 11:21:07 -0400

> networks now and soon that is enough big to justify working on this 
scheme?

Marc, 
See Erik Kline's answer from a few days ago (below). 0.1% is quite low, 
but that's still 1000 out of every 1 million ISP clients. Still a large 
amount for technical support to handle. But these customers will be
calling only if the 6to4 return path is sufficiently broken for 
them to feel the pain on the IPv6-enabled sites they go to. 

IMHO, only real life will tell if 6to4+NAT66 is really useful. That
will require a significant amount of IPv6 content to be available 
first. From an ISP point of view, it's merely a tool to be used if
that specific pain point becomes a problem. 

Erik Kline wrote: 
> I don't know if these numbers are relevant to anybody but me, but
> here's the latest:
> 
>     - of the clients in one of our experiments that connect to a
> dualstack hostname, 0.2% (up from 0.04% 2 years ago!) connect with
> native (or apparently native) IPv6, and an additional 0.1% connect
> with 6to4.

JF

My take on 6to4-PMT:
networks now and soon that is enough big to justify working on this 
scheme?

Marc.

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 28 Oct 2010 17:09:47 +0100

Le 10-10-28 16:21, [email-masked] a écrit :
> See Erik Kline's answer from a few days ago (below).

I saw it. I was responding in the generic way and gives others to 
document their findings.

> 0.1% is quite low,
> first.

well, an important content provider already is v6 enabled... for some 
providers, this single content provider generates a significant part of 
their trafic...

> From an ISP point of view, it's merely a tool to be used if

well, from what you wrote, it looks like an independent track 
experimental RFC is probably what you need.

Marc.

---

From: [email-masked]
Date: Thu, 28 Oct 2010 12:27:04 -0400

> providers, this single content provider generates a significant part of 

Available IPv6 content == AAAA sent by default, no strings attached

I believe the content provider you are referring to does not fall into
that category, although I admire their efforts to figure out the 
operational issues related to IPv6 deployment. 

JF

---

From: Erik Kline <[email-masked]>
Date: Thu, 28 Oct 2010 09:49:55 -0700

> translation beats cross-family translation.

IMHO nothing is worth enshrining this as a "valid use case" for NAT66.
 You're inviting a devil in to your house for tea and cake, and it may not
leave when you ask.  That there are still architectural/design flaws for
which NAT66 may ultimately be necessary I would be willing to admit, if only
for the sake of discussion.  But not this.  6to4 is one third today what it
was 2 years ago.  Let it pass in peace.

NATing from IPv4 to IPv6 for your customers leaves NAT a part of the IPv4
leaf network/administrative domain, and doesn't carry that practice forward
into IPv6.

As  (I believe) Albert Einstein said, "We can't solve problems by using the
same kind of thinking we used when we created them."  [Apologies if I'm
mistaken.]

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 28 Oct 2010 09:57:12 -0700

> them to feel the pain on the IPv6-enabled sites they go to.

I believe most of the brokenness has to do with in-home networks or
host configurations.

PMT will not fix broken 6to4, if i understand it right, it only
improves latency performance.

So, with or without PMT, 0.1% will still be broken  ... assuming 0.1%
brokenness is not the result of latency, if i understand all this
correctly.

> will require a significant amount of IPv6 content to be available

IPv6-only content, right? Because dual stack content with use IPv4.  I
personally don't think there will be such a thing a real IPv6-only
content that is meaningful to more than 1% of your subscribers,
hopefully those are not the broken 1%.  Maybe real IPv6-only p2p or
something like that.

> that specific pain point becomes a problem.

Great.  If you think there is value, you don't need the IETF's
permission, right?

Cameron

---

From: [email-masked]
Date: Thu, 28 Oct 2010 13:16:30 -0400

> brokenness is not the result of latency, if i understand all this

PMT improves return path routing, which affects latency, yes. 
Brokeness is not caused by latency but by broken 6to4 return 
reachability (the first is an effect, the second is the root cause). 
In this regard, PMT improving return routability does improve 6to4 
brokeness. Victor's and Yiu's draft is only a short-term solution 
to this problem, nothing more. 

> hopefully those are not the broken 1%.  Maybe real IPv6-only p2p or

I didn't mention IPv6-only content. I'm using Erik's number of 0.1%
of IPv6 users still using 6to4 in priority over IPv4. If that gets 
fixed in OS implementations by the time significant content is over v6, 
then there's isn't a problem to solve anymore. And we all go home happy. 

> Great.  If you think there is value, you don't need the IETF's

Not all vendors implement procotols without an RFC (or at least a 
draft to give them guidance). 

JF

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 28 Oct 2010 23:44:06 +0100

> This technical reality is destructive, and MUST NOT be ignored.

well, what I wrote is a proposal going forward:
- either there is a clear demonstration of a "good" number of 6to4 devices,
- if not, I suggested authors to go to the RFC-editor individual submission.

I think that was a constructive suggestion and fair.

>
> Putting  6rd in the same undifferentiated category as 6to4-PMT,

I did not. There was no "6rd" in the email I sent.

although 6rd permitted the largest deployment of native IPv6 addresses 
so far, with happy ISPs and happy customers, and without operational 
loose ends where it is applicable, doesn't contribute, IMHO, to promote 
availability of good quality IPv6.

Marc.

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 28 Oct 2010 15:51:32 -0700

I have to agree with Erik here. For the number of people that would have a significant enough customer base using 6to4 that they might consider PMT, the world would be MUCH better off with a handful of > /16 announcements in BGP, than having to deal with the NAT66 nonsense forever. Shortsighted hacks that bring along dangerous baggage MUST NOT be standardized. 

Do whatever you are going to do to support your customers, but don’t expect the world to standardize your model. 

Tony

From: [email-masked] [mailto:[email-masked]] On Behalf Of Erik Kline
Sent: Thursday, October 28, 2010 9:50 AM
To: Victor Kuarsingh
Cc: IPv6 Operations
Subject: Re: [v6ops] Reasons not to endorse NAT66/6to4

IMHO nothing is worth enshrining this as a "valid use case" for NAT66.  You're inviting a devil in to your house for tea and cake, and it may not leave when you ask.  That there are still architectural/design flaws for which NAT66 may ultimately be necessary I would be willing to admit, if only for the sake of discussion.  But not this.  6to4 is one third today what it was 2 years ago.  Let it pass in peace.

NATing from IPv4 to IPv6 for your customers leaves NAT a part of the IPv4 leaf network/administrative domain, and doesn't carry that practice forward into IPv6.

As  (I believe) Albert Einstein said, "We can't solve problems by using the same kind of thinking we used when we created them."  [Apologies if I'm mistaken.]

---

From: Rémi Després <[email-masked]>
Date: Fri, 29 Oct 2010 09:29:33 +0200

> - either there is a clear demonstration of a "good" number of 6to4 devices,

The more 6to4 users, the worse it is to make them unreachable at their 6to4 address.

> - if not, I suggested authors to go to the RFC-editor individual submission.

Always possible.
To become an RFC, however, "Once the RFC Editor thinks a document may be suited for RFC publication, the RFC Editor asks the IESG to review the documents for conflicts with the IETF standards process or work done in the IETF community."

The hope, in this context, is that IESG will have noted that adding NAT66 to 6to4 deteriorates 6to4 for those that use it today across 6to4 relays, and depend on its key property that 6to4 addresses can be used for incoming reachability.
(This feature is  completely lost).

BTW, do you acknowledge this fact, or do you negate it, or do you consider it as uncertain?

> I did not. There was no "6rd" in the email I sent.

True!
Sorry for this mistake. 
I still don't trace how I made it (maybe a copy and paste while working in parallel on two answers). 
Anyway, thanks for correcting me.

Regards,
RD

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 29 Oct 2010 07:51:13 +0000

Hi Marc,

Sorry to jump in late. I think your proposal is fair. The reason why  
we presented this to IETF is because we wanted to document which may  
happen in some ISP networks. Some ISP may deploy it w/ or w/o RFC #.  
Yes 6to4 has finished it's job, I really hope it's number will drop to  
0 next year. Meanwhile, we still have few hundred thousand users using  
6to4. Victor, Scott and JF have voice their opinions why we did it. We  
presented it and we wanted to hear what the WG thinks. If everybody  
thinks this is a bad idea, we at least have an I-D that explains this.  
One day if somebody saw this in the wild, we would have a reference.

Cheers,
Yiu

On Oct 28, 2010, at 4:53 AM, "Marc Blanchet"  
<[email-masked]> wrote:

> My take on 6to4-PMT:
> - not nice. a hack. (not our first hack, will not be the last one,   
> not the worst one, but you may have a different opinion)
> - pretty short time lifetime (well, things live around much longer  
> than usually thought of, but anyway: in the grand scheme of things,  
> should be "short")
> - I understand (and agree to some level) the reasons for deploying  
> such schemes.
> - if this is being implemented and deployed, then it would be good  
> to be documented somewhere in an RFC.
> another: what is the real footprint of 6to4-enabled devices in  
> broadband networks now and soon that is enough big to justify  
> working on this scheme?

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 29 Oct 2010 09:23:24 +0100

> thinks this is a bad idea, we at least have an I-D that explains this.

great that you did document it. If it gets implemented and deployed, 
then the best thing is to get it documented.

> One day if somebody saw this in the wild, we would have a reference.

However, I-D expires. That is why I suggested that you might want to 
think about going individual submission to RFC-editor for experimental 
track. That will give a permanent document that can be more easily 
referenced.

Marc.

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 29 Oct 2010 11:01:32 +0100

> (This feature is  completely lost).

The IESG may state whatever they think about the 
proposed-experimental-RFC. Whatever they write as an IESG note, it still 
gets one of the goals which is documenting a specification of an 
implementation that is deployed and used on the Internet.

Marc.

---

From: <[email-masked]>
Date: Fri, 29 Oct 2010 12:09:42 -0600

"6to4 is one third today what it was 2 years ago."

Could you please elaborate on this interesting fact? Because it runs contrary to everything I have seen on the matter.

- Scott

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 29 Oct 2010 12:21:44 -0700

Rémi Després wrote:

> > equipment which has a "current set" of features (and as noted, this
> > often includes 6to4 default operation).
> 
> That's why current 6to4 users shouldn't lose the ability to be reached
> at their 6to4 address, including by hosts that have native-Ipv6
> addresses and routes via 6to4 relays.

I don't believe Victor's PMT breaks that ability.  

The 6to4 host is still accessible via its 6to4 address, which won't 
go through the provider's NAT66.  The provider *could* break that 
ability (just like they could break 6to4 without PMT), but I don't 
recall draft-kuarsingh-v6ops-provider-managed-tunnel suggesting
that providers break this ability.

-d

---

From: james woodyatt <[email-masked]>
Date: Fri, 29 Oct 2010 12:37:53 -0700

> I don't believe Victor's PMT breaks that ability.  

I'm certain it does.

> that providers break this ability.

I have native dual-stack IPv4/IPv6 service on my home network.  I operate my own 6to4-relay that encapsulates all traffic to 2002::/16 destinations in the IPv4 tunnel and sends it to my service provider's IPv4 default router.

Say you're located at a 6to4-PMT subscriber site.  I want to reach your host at its 6to4 address (let's say the address was referred to me somehow by somebody using 6to4 to communicate with your host, e.g. your own host itself).

So I send a SYN packet from 2001:db8::1 to 2002:aabb:ccdd::$IID.  Where does the ACK go?  Through the 6to4 relay at 192.88.99.1 and then through the NAT66, which rewrites the source address so I don't recognize it.  Kaboom.  Fail.

---

From: Gert Doering <[email-masked]>
Date: Fri, 29 Oct 2010 22:06:28 +0200

Hi,

> that providers break this ability.

If the connection comes from a native IPv6 (non 6to4) host, the reply
packet will go through the NAT66, and will arrive with a different 
address than the other end is expecting to hear from.

Sounds broken to me.

(6to4<->6to4 will not be broken, but that is not broken today either)

Gert Doering
        -- NetMaster

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 29 Oct 2010 13:17:48 -0700

> From: james woodyatt [mailto:[email-masked]]
> Sent: Friday, October 29, 2010 12:38 PM
> To: v6ops v6ops
> Cc: Dan Wing
> Subject: Re: [v6ops] Reasons not to endorse NAT66/6to4(ref draft-
> kuarsingh-v6ops-provider-managed-tunnel-00)
> 
> I have native dual-stack IPv4/IPv6 service on my home network.  I
> operate my own 6to4-relay that encapsulates all traffic to 2002::/16
> destinations in the IPv4 tunnel and sends it to my service provider's
> IPv4 default router.
> 
> Say you're located at a 6to4-PMT subscriber site.  I want to reach your
> host at its 6to4 address (let's say the address was referred to me
> somehow by somebody using 6to4 to communicate with your host, e.g. your
> own host itself).
> 
> So I send a SYN packet from 2001:db8::1 to 2002:aabb:ccdd::$IID.  Where
> does the ACK go?  Through the 6to4 relay at 192.88.99.1 and then
> through the NAT66, which rewrites the source address so I don't
> recognize it.  Kaboom.  Fail.

I was thinking of ICE, running over UDP (e.g., with XMPP or SIP), which
doesn't break.  You are right that TCP breaks.  Thanks.

-d

---

From: james woodyatt <[email-masked]>
Date: Fri, 29 Oct 2010 13:32:11 -0700

> doesn't break.  You are right that TCP breaks.  Thanks.

Same thing happens with IKE, which is UDP.  Basically, anything where my host sends a packet to yours and expects to get a response packet where your source address matches my destination address, i.e. most connection-oriented applications and anything that sets up a host-to-host association for a traffic flow, e.g. SCTP.

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 29 Oct 2010 13:36:19 -0700

> > I was thinking of ICE, running over UDP (e.g., with XMPP or SIP),
> > which doesn't break.  You are right that TCP breaks.  Thanks.
> 
> Same thing happens with IKE, which is UDP.  Basically, anything where
> my host sends a packet to yours and expects to get a response packet
> where your source address matches my destination address, i.e. most
> connection-oriented applications and anything that sets up a host-to-
> host association for a traffic flow, e.g. SCTP.

*Nodding in agreement*.  Nonetheless, I was thinking of ICE.  Mea culpa, 
once again.

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 30 Oct 2010 10:04:09 +1300

> So I send a SYN packet from 2001:db8::1 to 2002:aabb:ccdd::$IID.  Where does the ACK go?  Through the 6to4 relay at 192.88.99.1 and then through the NAT66, which rewrites the source address so I do…

How does the initiator know that the listener's address is 2002:aabb:ccdd::$IID
in the first place? Did the listener site forget to install two-faced DNS, which
seems to be the only way this could be hacked around to work?

It's no real surprise that a server behind a NAT doesn't work properly without
a kludge. NAT doubleplusungood, once again.

   Brian

---

From: james woodyatt <[email-masked]>
Date: Fri, 29 Oct 2010 14:49:19 -0700

> seems to be the only way this could be hacked around to work?

The listener didn't ask to be located behind the provider NAT66 middlebox.

The listener host probably used Dynamic DNS to register all its global-scope interface addresses.  Or maybe the initiator is an FTP server that's trying to open the data port on the client host in response to a PORT command.  Or maybe the initiator is a BitTorrent peer.  Or maybe the initiator is an IKE responder that's been manually configured with the 6to4 address in its security policy database.  Or.  Or.  Or.

Yes, this would be a good time to plug I-D.carpenter-referral-ps again.  I swear, it's like playing a game of whack-a-mole.

---

From: Rémi Després <[email-masked]>
Date: Sat, 30 Oct 2010 09:49:52 +0200

Dan,

Le 29 oct. 2010 à 22:06, Gert Doering a écrit :
> ...If the connection comes from a native IPv6 (non 6to4) host, the reply

Same understanding.

> (6to4<->6to4 will not be broken, but that is not broken today either)

Idem.

Regards,
RD

---

From: Joel Jaeggli <[email-masked]>
Date: Sat, 30 Oct 2010 11:32:17 -0700

The threads associated with the discussion of:

draft-kuarsingh-v6ops-provider-managed-tunnel-00

have generated order of a hundred messages from more than two dozen
participants since 10/21.

While it would probably be useful to characterize a couple of the more
cogent points of argumentation, I think a simpler observation is that if
it were proposed, that there would clearly be strong opposition to this
document as a working group item and I don't see it advancing along that
track.

In that mean time I think it is safe to let this thread cool off.

thanks
joel

---

From: Victor Kuarsingh <[email-masked]>
Date: Sun, 31 Oct 2010 14:31:27 -0400

James,

Agreed, there are defiantly issues when NATing (even 6to6).

Just as an additional point, one of the use cases is when IPv4 runs out and
the customer is now behind a provider NAT44 (which in most cases means
NAT444 - the infamous double NAT).

At this point many operations will need to apply either RFC1918 or (key
issue) public Space (either from their own pool as overlap, from RIR special
block, camped space etc).  In the second case, NAT is now unavoidable for
such customers (in IPv4 space).  So we are in a "bad" scenario either way.
In this case, 6to4 (if on by default) will activate and be broken (since no
real return path for that address exits in the 6to4 model).

In this case, IPv4 will unlikely have a level of additional brokenness.  In
this case, the single NAT66 may still be better then the double NAT44
(NAT444).

An additional NAT66 will enter the the Internet world, one way or the other
(i.e. Dual homing enterprises), this may also be a good chance to see what
the actual real world impacts are of this type of translation are. (it is
also very easy to turn off/on).

Just an additional set of thoughts.

Regards,

Victor

On 29/10/10 5:49 PM, "james woodyatt" <[email-masked]> wrote:

> The listener host probably used Dynamic DNS to register all its global-scope
> interface addresses.  Or maybe the initiator is an FTP server that's trying to
> open the data port on the client host in response to a PORT command.  Or maybe
> the initiator is a BitTorrent peer.  Or maybe the initiator is an IKE
> responder that's been manually configured with the 6to4 address in its
> security policy database.  Or.  Or.  Or.
> 
> Yes, this would be a good time to plug I-D.carpenter-referral-ps again.  I
> swear, it's like playing a game of whack-a-mole.
> 
> 
> --

---

From: Fred Baker <[email-masked]>
Date: Sun, 31 Oct 2010 11:45:17 -0700

On Oct 31, 2010, at 11:31 AM, Victor Kuarsingh wrote:

> Just as an additional point, one of the use cases is when IPv4 runs out and the customer is now behind a provider NAT44 (which in most cases means NAT444 - the infamous double NAT).

yes, of course. And we already have a lot of that; Verizon, at the recent Google IPv6 conference, said they have 70 instances of 10.0.0.0/8 in their network, and I have to believe that many of them have residential routers, which generally incorporate NAT, behind them. Service in Latin America, Central Asia, the middle east, and Africa have used service provider NAT for a long time. So this is not exactly new.

I would lump that under "address amplification" - making there be more addresses by re-using them in a context. You probably are aware of the implications of the service, but I'll make that explicit. People in those regions don't generally talk about "being on the Internet". They talk about how many "steps away" they are from the Internet. They don't generally offer services from those domains; it's far more common to find an Africa person using a gmail or yahoo address than a local address, for example, and web sites tend to be in places that have good accessibility, usually hosting companies. This is true for all the reasons Keith has been pointing out - from their perspective, the service works better, as they are not forced to simply be a consumer of it.

So, yes, one of the use cases of IPv4/IPv4 NAT will be continuity of business during the coexistence period. That is an absolute fact, and not much worth discussing from my perspective. At least not on this list.

---

From: Victor Kuarsingh <[email-masked]>
Date: Sun, 31 Oct 2010 15:03:18 -0400

Fred,

Understood, I just made mention of it as it has a connection to some
protocols like 6to4, and Teredo - which break under NAT444 (in some cases)
and are there to provide IPv6 connectivity.

Issue 1 - Teredo under NAT444 is problematic (reference
draft-donley-nat444-impacts)
Issue 2 - 6to4 under NAT444 when non-RFC1918 addressing is used

I am not here to actually discuss NAT444 on it's own - within v6ops.

Regards,

Victor

On 31/10/10 2:45 PM, "Fred Baker" <[email-masked]> wrote:

>> the customer is now behind a provider NAT44 (which in most cases means NAT444
>> - the infamous double NAT).
> 
> yes, of course. And we already have a lot of that; Verizon, at the recent
> Google IPv6 conference, said they have 70 instances of 10.0.0.0/8 in their
> network, and I have to believe that many of them have residential routers,
> which generally incorporate NAT, behind them. Service in Latin America,
> Central Asia, the middle east, and Africa have used service provider NAT for a
> long time. So this is not exactly new.
> 
> I would lump that under "address amplification" - making there be more
> addresses by re-using them in a context. You probably are aware of the
> implications of the service, but I'll make that explicit. People in those
> regions don't generally talk about "being on the Internet". They talk about
> how many "steps away" they are from the Internet. They don't generally offer
> services from those domains; it's far more common to find an Africa person
> using a gmail or yahoo address than a local address, for example, and web
> sites tend to be in places that have good accessibility, usually hosting
> companies. This is true for all the reasons Keith has been pointing out - from
> their perspective, the service works better, as they are not forced to simply
> be a consumer of it.
> 
> So, yes, one of the use cases of IPv4/IPv4 NAT will be continuity of business
> during the coexistence period. That is an absolute fact, and not much worth
> discussing from my perspective. At least not on this list.