Subject: IPv6 only host NAT64 requirements?

From: Ole Troan <[email-masked]>
Date: Mon, 13 Nov 2017 10:50:40 +0800

At the hackathon there was quite a bit of testing of IPv6 only hosts with access to the IPv4 network via a NAT64.

While many applications work well on a classic IPv6 only host, there are a few things required to make all applications work.

- Must be able to do NAT64 prefix discovery (RFC6052)
- Synthesise IPv6 address from an IPv4 literal (RFC7050)

This is to be able to deal with IPv4 address literals. Which are common in protocols like SIP/ICE/STUN.
These can be implemented directly in applications, or it can be implemented in the host stack (although application might still have to change).

- Should do local DNS64 to support DNSSEC (RFC6147) (if you do validation).

A DNS64 service in the network looks like a man in the middle attack, so to support DNSSEC, validation should happen before synthesizing, and must be done on the host itself.

If this is the direction we want to go. Encourage IPv6 only host deployments (as opposed to dual stack hosts), are these requirements we'd like to add to the IPv6 node requirements document? Somewhere else?

Best regards,
Ole

---

From: Ca By <[email-masked]>
Date: Mon, 13 Nov 2017 03:32:22 +0000

On Sun, Nov 12, 2017 at 6:51 PM Ole Troan <[email-masked]> wrote:

> While many applications work well on a classic IPv6 only host, there are a
> few things required to make all applications work.
>
> These can be implemented directly in applications, or it can be
> implemented in the host stack (although application might still have to
> change).
>
> - Should do local DNS64 to support DNSSEC (RFC6147)(if you do validation).
>
> A DNS64 service in the network looks like a man in the middle attack, so
> to support DNSSEC, validation should happen before synthesizing, and must
> be done on the host itself.
>
> If this is the direction we want to go. Encourage IPv6 only host
> deployments (as opposed to dual stack hosts), are these requirements we'd
> like to add to the IPv6 node requirements document? Somewhere else?
>

I am not optimistic on the demand / need / value of dnssec in any scenario
....let alone an ipv6-only host validating an ipv4-only dns name. If the
folks operating this service cared, they could operate the server with
signed v6 names.  It is more reasonable in todays internet to asked the
server (lets assume most signed name scenarios are servers) to be setup
right (with v6). There is not a compelling reason why having v6 is
unattainable today for named nodes.

With 20 years of experience with ipsec as an ipv6 node requirement, i think
it is safe to say the IETF foisting requirents into the network layer has
caused more confusion (ipv6 is more secure because everything has ipsec!)
and hacks (ospfv3 ...) than actual true security benefit.

> Best regards,
> Ole
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 13 Nov 2017 11:58:22 +0800

Hi Ole,

I was also thinking on this yesterday after the hackathon and I thing from that talk it is obvious that I will support that.

Also thought about this:

Could the “IPv6 node requirements document” include also a consideration for the same you mention here, in case there is IPv4-only in a dual-stack LAN with IPv6-only access?

I’m almost sure that this is out of the scope of the 6man charter, but I also feel that this is somehow our job … alternatively what is the correct place to do that? May be a new sunset4 document? Or int-area? The point here is an IPv4-only host being used in a network using IPv6-only for the access ...

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Ole Troan <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 13 de noviembre de 2017, 11:46
Para: 6man WG <[email-masked]>
Asunto: IPv6 only host NAT64 requirements?

    

    

    Best regards,
    Ole

**********************************************
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 exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 Nov 2017 13:49:47 +0800

Jordi,

> I was also thinking on this yesterday after the hackathon and I thing from that talk it is obvious that I will support that.

Thanks.

> Could the “IPv6 node requirements document” include also a consideration for the same you mention here, in case there is IPv4-only in a dual-stack LAN with IPv6-only access?

Not sure I understand what dual stack LAN with IPv6 only access means.
If it is dual-stack, I'd assume you also have IPV4 routing.

> I’m almost sure that this is out of the scope of the 6man charter, but I also feel that this is somehow our job … alternatively what is the correct place to do that? May be a new sunset4 document?…

If you are talking about the reverse problem, an IPv4 only host requiring access to the IPv6 Internet.
Or an isolated IPv4 only host in an IPv6 only network... I'd think that would be better suited for sunset4.

Cheers,
Ole

---

From: Tim Chown <[email-masked]>
Date: Mon, 13 Nov 2017 13:08:12 +0000

Hi,

> On 13 Nov 2017, at 02:50, Ole Troan <[email-masked]> wrote:
> 

draft-ietf-6man-rfc6434-bis-02 includes a (very short) Section 10 on transition, see https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-02#section-10

If someone wishes to propose text in a new section 10.2 on “IPv6-only” operation, we could include that if the WG agrees.  This could be something for TimW to add as a question when the draft is presented in 6man.

Tim

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 13 Nov 2017 13:27:10 +0000

@Ole, I agree. Just swap the RFC#.

@Tim,

If someone wishes to propose text in a new section 10.2 on “IPv6-only” operation, we could include that if the WG agrees.  This

It might be useful to have some text in section 14 (v6 router) to accommodate v4 hosts/apps in case of v6-only uplink/ WAN.

Cheers,
Rajiv

On Nov 13, 2017, at 8:08 AM, Tim Chown <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

On 13 Nov 2017, at 02:50, Ole Troan <[email-masked]<mailto:[email-masked]>> wrote:

- Should do local DNS64 to support DNSSEC (RFC6147)
(if you do validation).

Tim
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Tim Chown <[email-masked]>
Date: Mon, 13 Nov 2017 13:42:44 +0000

> On 13 Nov 2017, at 13:27, Rajiv Asati (rajiva) <[email-masked]> wrote:
> 

I think the trick for 6434bis is deciding what the scope of the doc is. Such suggestions, while they certainly have merit, are a slippery slope to adding many things, as we’ve seen when Jordi started proposing transition mechanisms for RFC7084-bis.  

Steer from the WG is, as ever, very welcome.

Tim

> Cheers,
> Rajiv  
> 
> 
> On Nov 13, 2017, at 8:08 AM, Tim Chown <[email-masked]> wrote:
> 
>> Hi,
>>

---

From: Ca By <[email-masked]>
Date: Mon, 13 Nov 2017 13:54:23 +0000

On Mon, Nov 13, 2017 at 5:43 AM Tim Chown <[email-masked]> wrote:

> >> If someone wishes to propose text in a new section 10.2 on “IPv6-only”
> operation, we could include that if the WG agrees.  This
> >
> > It might be useful to have some text in section 14 (v6 router) to
> accommodate v4 hosts/apps in case of v6-only uplink/ WAN.
>
> I think the trick for 6434bis is deciding what the scope of the doc is.
> Such suggestions, while they certainly have merit, are a slippery slope to
> adding many things, as we’ve seen when Jordi started proposing transition
> mechanisms for RFC7084-bis.
>

Yes , slippery slope indeed. And you would have to deal with me opposing
the case being included.

I have a network with 10s of millions of ipv6-only nodes, none of which can
so dnssec (neither android nor ios support it) and the implication that
these nodes are no longer ipv6 since they don't do dnssec is ludicrous.

i think this is just folks tryjng to raise the bar against nat64, again,
with nonesense usecass that users and operators don’t want or care about.

Sad

> >>> At the hackathon there was quite a bit of testing of IPv6 only hosts
> with access to the IPv4 network via a NAT64.
> >>>
> >>> While many applications work well on a classic IPv6 only host, there
> are a few things required to make all applications work.
> >>>
> >>> A DNS64 service in the network looks like a man in the middle attack,
> so to support DNSSEC, validation should happen before synthesizing, and
> must be done on the host itself.
> >>>
> >> draft-ietf-6man-rfc6434-bis-02 includes a (very short) Section 10 on
> transition, see
> https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-02#section-10
> >>
> >> If someone wishes to propose text in a new section 10.2 on “IPv6-only”
> operation, we could include that if the WG agrees.  This could be something
> for TimW to add as a question when the draft is presented in 6man.
> >>
> >> Tim

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 Nov 2017 22:55:50 +0800

Cameron,

> Yes , slippery slope indeed. And you would have to deal with me opposing the case being included.
> 
> I have a network with 10s of millions of ipv6-only nodes, none of which can so dnssec (neither android nor ios support it) and the implication that these nodes are no longer ipv6 since they don't do dnssec is ludicrous.
> 
> i think this is just folks tryjng to raise the bar against nat64, again, with nonesense usecass that users and operators don’t want or care about.

I wanted to put the DNSSEC requirement out there. After having talked with a few people here, it seems doing validation on a off-box resolver isn't any worse than what's typically done today. I wouldn't mind dropping that requirement.

You appear to have missed the two other requirements I suggested in the original email?
This wouldn't be the exact opposite of raising the bar against NAT64. It would be to try to ensure NAT64 worked for all IPv6 only nodes.

Cheers,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Mon, 13 Nov 2017 16:24:30 +0100

In your letter dated Mon, 13 Nov 2017 10:50:40 +0800 you wrote:
>deployments (as opposed to dual stack hosts), are these requirements 
>we'd like to add to the IPv6 node requirements document? Somewhere else

Personally I don't like how NAT64 requires an IPv6 stack to deal with all
kinds of IPv4 issues. So for IPv6 node requirements, it should not go
beyond the level of MAY.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 13 Nov 2017 16:35:34 +0100

>unattainable today for named nodes.

DNSSEC is something that works today. Opinions are divided on what security
it offers. Some people like it way more than the traditional CA system. 
Other people believe that we should continue making random changes to the CA
system in the hope that one day it will be secure.

The problem for people who do local DNSSEC validation is that if neither the
NAT64/DNS64 operator nor the operator of the target server cares about 
DNSSEC/IPv6 then it just breaks.

If all server operators cared, then there would be no need for NAT64/DNS64
so the problem would not exist in the first place.

If the NAT64/DNS64 operator cared, then they would offer be dual stack IPv4
or a tunneling based transition technology that doesn't break DNSSEC.

I guess the good news is that at least one group of people writing a local
DNSSEC validating resolver (getdns) are aware of this issue and are adding
code to handle this situation.

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 Nov 2017 23:35:43 +0800

Philip,

> kinds of IPv4 issues. So for IPv6 node requirements, it should not go

Yes, that's certainly the bind we are in. Are we going to require all IPv6 only nodes to be able to communicate with IPv4? And what does that entail? Do you have examples of "all kinds of IPv4 issues"?

Apart from the requirement of NAT64 prefix discovery and IPv4 synthesising, is there anything you don't need to do anyway?
I can't quite see ICE/STUN going away, just because the end to end path is IPv6.

While I'm also concerned about the consequences of carrying IPv4 debt in all IPv6 implementations, the alternative seems to be that we are stuck with Dual stack forever (for some definition of forever). This would at least allow us to move to single stack IPv6. Which appears to me to be a step forward. And we're very close to that already, and there are millions of devices already implementing it.

Cheers,
Ole

---

From: Ca By <[email-masked]>
Date: Mon, 13 Nov 2017 15:36:56 +0000

On Mon, Nov 13, 2017 at 6:56 AM Ole Troan <[email-masked]> wrote:

> > >> If someone wishes to propose text in a new section 10.2 on
> “IPv6-only” operation, we could include that if the WG agrees.  This
> > >
> > I have a network with 10s of millions of ipv6-only nodes, none of which
> can so dnssec (neither android nor ios support it) and the implication that
> I wanted to put the DNSSEC requirement out there. After having talked with
> a few people here, it seems doing validation on a off-box resolver isn't
> any worse than what's typically done today. I wouldn't mind dropping that
> requirement.
>
> This wouldn't be the exact opposite of raising the bar against NAT64. It
> would be to try to ensure NAT64 worked for all IPv6 only nodes.
>
> Cheers,
> Ole

Ole,

Yes, the first 2 are not objectionable and are already well know,
documented and deployed as part of various transition solutions.

My feeling is the plane is already in flight and operators do not need any
additional guidance / confusion from the ietf.

In short, this is a solved problem and the industry needs more stability
and less tweaking .... especially in something fundamental like the node
definition

http://www.worldipv6launch.org/apps/ipv6week/measurement/images/graphs/T-MobileUSA.png

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 Nov 2017 23:45:05 +0800

Cameron,

> 
> Yes, the first 2 are not objectionable and are already well know, documented and deployed as part of various transition solutions.
> 
> My feeling is the plane is already in flight and operators do not need any additional guidance / confusion from the ietf.
> 
> In short, this is a solved problem and the industry needs more stability and less tweaking .... especially in something fundamental like the node definition

This isn't guidance to operators, this is guidance to implementors.
As we found during the hackathon, multiple stacks do lack the first two. And as a consequence applications break.
Now you can argue if we want to put the burden of this on applications or on the host stack. If the former the node requirements document might not be the right place.

> http://www.worldipv6launch.org/apps/ipv6week/measurement/images/graphs/T-MobileUSA.png

I thought this deployment provided dual stack service? 464XLAT, no?
That's a different problem than what we are trying to solve here.

Cheers,
Ole

---

From: Ca By <[email-masked]>
Date: Mon, 13 Nov 2017 15:46:12 +0000

On Mon, Nov 13, 2017 at 7:36 AM Ole Troan <[email-masked]> wrote:

> Yes, that's certainly the bind we are in. Are we going to require all IPv6
> only nodes to be able to communicate with IPv4? And what does that entail?
> Do you have examples of "all kinds of IPv4 issues"?
>
> Apart from the requirement of NAT64 prefix discovery and IPv4
> synthesising, is there anything you don't need to do anyway?

1. ICE and STUN are apps, and they should be fixed in the app layer not
network.

2.  ICE and STUN work great today with v4 and v6 peer candidates,
especially when combined with their close cousin TURN, in TRAM WG and
specifically https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/

> While I'm also concerned about the consequences of carrying IPv4 debt in
> all IPv6 implementations, the alternative seems to be that we are stuck
> with Dual stack forever (for some definition of forever). This would at
> least allow us to move to single stack IPv6. Which appears to me to be a
> step forward. And we're very close to that already, and there are millions
> of devices already implementing it.
>
> Cheers,
> Ole

---

From: Ca By <[email-masked]>
Date: Mon, 13 Nov 2017 15:52:28 +0000

On Mon, Nov 13, 2017 at 7:45 AM Ole Troan <[email-masked]> wrote:

> > My feeling is the plane is already in flight and operators do not need
> any additional guidance / confusion from the ietf.
> >

Ok, then i would proceed with caution and weigh heavily the feedback from
implementors

> Now you can argue if we want to put the burden of this on applications or
> on the host stack. If the former the node requirements document might not
> be the right place.
>
> >
> >

My definition of ipv6-only includes 464xlat

To your point, a large percentage of the tmobile case is 6555bis with
nat64/dns64.

Based on the picture, you can probably guess when 6555bis was implemented
ands its relative impact

---

From: Ole Troan <[email-masked]>
Date: Tue, 14 Nov 2017 00:09:11 +0800

> 1. ICE and STUN are apps, and they should be fixed in the app layer not network.

Right, AFAIK IOS solves it at the stack level (with some application requirements). So this can go both ways.

> 
> 2.  ICE and STUN work great today with v4 and v6 peer candidates, especially when combined with their close cousin TURN, in TRAM WG and specifically https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/

But we did find ICE/STUN applications not working in an IPv6 only + NAt64 network at the hackathon.

Cheers,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Mon, 13 Nov 2017 17:16:29 +0100

>Yes, that's certainly the bind we are in. Are we going to require all 
>IPv6 only nodes to be able to communicate with IPv4? And what does that 
>entail? Do you have examples of "all kinds of IPv4 issues"?
>

One that really breaks my code, and is relevant to 6man is the guarantee in
IPv6 error ICMPs:

(c) Every ICMPv6 error message (type < 128) MUST include as much of
    the IPv6 offending (invoking) packet (the packet that caused the
    error) as possible without making the error message packet exceed
    the minimum IPv6 MTU

>step forward. And we're very close to that already, and there are 
>millions of devices already implementing it.

In new applications that are simple from a networking point of view, it should
be possible to come up with a design that works well for both dual stack and
NAT64.

Operators who have lots of legacy devices are likely to run a dual stack
network. So hosts that are expected to work in such an environment have to
implement dual stack.

I'm not sure how (outside 3GPP) anyone can transition to NAT64. You have to
make sure that all devices that need to connect support NAT64. To do that,
you probably want to run dual stack for a while to make sure everything 
supports IPv6 properly. 

But for host software there is a lot more incentive to support dual stack then
to do the extra step for NAT64.

The big problem I see for NAT64 is that for old IPv4-only applications you 
have to make two fundamental changes to the application. The first to 
make sure that the application handles IPv6 in every possible way. And a
second pass that makes sure that every place where an IPv4 address literal 
is handled, works with NAT64. 

For an application writer it is better to try to avoid doing the second pass.

---

From: Ca By <[email-masked]>
Date: Mon, 13 Nov 2017 16:16:24 +0000

> network at the hackathon.

The ICE needs to be paired with a dual stack TURN server, i believe that is
the correct way to handle this scenario

That way, the peers always see v4 and v6 candidates

The issue you saw was that the v6 host was only presented with v4 peers
from ICE?

---

From: Ole Troan <[email-masked]>
Date: Tue, 14 Nov 2017 00:17:09 +0800

Cameron,

> My definition of ipv6-only includes 464xlat

Terminology is tricky. As proven by Jordi's presentation in v6ops today.

The difference as I see it between IPv6 only + NAT64 and 464XLAT is that in the former an IPv4 application cannot work.
While in the latter the host has an IPv4 address and the IPv4 only application works just as if it is provisioned with IPv4 using any other means. That being native, LW46, MAP-E, MAP-T, L2TP, Public4over6, DSTM, 2473, DS-lite...

Different use cases. While 464XLAT is a way to tunnel IPv4 across an IPv6 only access network (albeit with a null encap. :-)), IPv6 only + NAT64 is about delivering IPv6 only to hosts and applications. Applications would only have an IPv6 address to bind to. This use case would be much more akin to an enterprise network or home network.

> To your point, a large percentage of the tmobile case is 6555bis with nat64/dns64.
> 
> Based on the picture, you can probably guess when 6555bis was implemented ands its relative impact

:-)

Cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 14 Nov 2017 00:30:38 +0800

Cameron,

> The ICE needs to be paired with a dual stack TURN server, i believe that is the correct way to handle this scenario
> 
> The issue you saw was that the v6 host was only presented with v4 peers from ICE?

Yep. Agree with the solution.
Unless If you synthesized the IPv4 address and went through a NAT64 instead of the TURN you could have a more direct path. Or not.

Cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 14 Nov 2017 00:34:59 +0800

Philip,

>    error) as possible without making the error message packet exceed

Right. But when is that an actual issue for applications?
(Where I'm not going to reply with, well ICMPv6 errors a) either don't make it there b) are ignored by the host stack / application c) are heavily throttled d) suffered that faith anyway because of some MPLS link or whatnot...) :-)

> For an application writer it is better to try to avoid doing the second pass.

Then we are stuck with dual stack.
What Randy and Jen set out to try in the IETF experiment was to figure out if it would be possible to do IPv6 only + NAT64. Identify what was broken and then get that fixed. If we're stuck with dual stack (or IPv4 only), then we're not moving towards the end-goal, are we?

Ole

---

From: Philip Homburg <[email-masked]>
Date: Mon, 13 Nov 2017 18:11:15 +0100

>Right. But when is that an actual issue for applications?

First, I naively put this in my TCP implementation. Technically that's
not an application, though user land TCP does occur.

It also breaks my traceroute implementation.

>What Randy and Jen set out to try in the IETF experiment was to figure 
>out if it would be possible to do IPv6 only + NAT64. Identify what was 
>broken and then get that fixed. If we're stuck with dual stack (or IPv4 
>only), then we're not moving towards the end-goal, are we?

>From a host point of view, I very much want to be dual stack. No magic.
What goes over the wire is what the application sees. IPv6 is complex enough
on its own. Adding DNS64/NAT64 make it less likely that people can actually
understand what is going on. 

Hosts being dual stack doesn't say anything about backbone networks. You
can do 464xlat on access routers or any other kind of IPv4 tunneling
technology. By tunneling on access routers you can even preserve a 1500 octet
MTU for IPv4.

In my view, the way we move to the end goal is when some networks really don't
have any IPv4 anymore. 

When IPv6-only eyeball networks appear that don't offer any kind of IPv4
connectivity, content providers either add support for IPv6 or they lose that
group of potential customers.

After a while, cheap consumer networks just drop IPv4 because it too expensive
to maintain. 

That's when IPv4 becomes truly legacy: you may have IPv4 connectivity at work,
but possible not at home. Not at a random place that offers wifi, not in
your hotel.

In corporate environments, assuming that all legacy applications can get
rewritten to support IPv6, the next step is to install proxies that offer
access to the few essential external services that are still IPv4 only.
Though possibly, those services start installing reverse proxies to offer
IPv6.

The only thing offering NAT64 to hosts does is making access networks IPv6-only
while introducing a lot of complexity without increasing end-to-end IPv6
connectivity.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 14 Nov 2017 02:16:44 +0900

> group of potential customers.

And how are those eyeball networks going to enter the market, given that
they don't provide access to IPv4 content but their competitors do? Seems
that they can only do that if pretty much all content is available over
IPv6. That leaves us stuck at the chicken and egg problem again.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 13 Nov 2017 20:09:08 +0100

>IPv6. That leaves us stuck at the chicken and egg problem again.

If your core business is IPv4, then in my opinion it doesn't make much 
sense to transition to a network setup where you tunnel your IPv4 traffic
over IPv6. 

As long as an eyeball network has plenty of IPv4 address and there is no
pressure from content providers, there is no point in transitioning to IPv6.

Moving bulk traffic (and bulk connections) to IPv6 make sense if all IPv4
traffic goes through a CGN. 

If an ISP has a full IPv6 setup to handle large volume traffic, and only has
to maintain an IPv4 CGN for content that doesn't want to move to IPv4, then
it is possible that slowly IPv4 performance will get worse. And then content
providers may see an incentive to move to IPv6. For some content providers,
accidentally kiling geolocation in order to improve CGN efficiency may
give them the nudge they need.

In the end, the only argument that seems to make economic sense is that
an IPv4 address is more expensive than an IPv6 address. And that traffic
through a CGN is more expensive than through a router.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 14 Nov 2017 09:46:10 +1100

Is there any reason to run DNS64 at all these days?  ipv4only.arpa can be a preconfigured
zone which allows CLAT to get its mapping.  All the phones have CLAT support.  Can we just
make DNS64 historic and let the phones run all IPv4 connections through CLAT rather than
having to stuff up DNSSEC and have IPv6 connections terminate in IPv4 servers without
the application knowing?

Mark

> On 14 Nov 2017, at 4:11 am, Philip Homburg <[email-masked]> wrote:
> 

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

---

From: Philip Homburg <[email-masked]>
Date: Tue, 14 Nov 2017 00:08:26 +0100

> Is there any reason to
> run DNS64 at all these days?  ipv4only.arpa can be a preconfigured
> zone which allows CLAT to get its mapping.  All the phones have
> CLAT support.  Can we just make DNS64 historic and let the phones
> run all IPv4 connections through CLAT rather than having to stuff
> up DNSSEC and have IPv6 connections terminate in IPv4 servers
> without the application knowing?

If NAT64 was limited to 3GPP interfaces then not a lot of people would care.

The problem started when a vocal group tried to push NAT64 as a general
purpose mechanism for providing IPv4 access.

In that context, there are lots of devices that do implement IPv6, but
do not implement CLAT.

So without DNS64 those devices would lose access to the IPv4 internet.

If you are willing have a stateful NAT box in your network, and requiring
host changes is acceptable, then ds lite is in interesting alternative. 
One that avoids having a NAT function on the host.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 14 Nov 2017 10:22:45 +1100

> On 14 Nov 2017, at 10:08 am, Philip Homburg <[email-masked]> wrote:
> 
>> Is there any reason to

I’m aware of the above.  I’m trying to workout if DN64 was turned off
today and replace with a preconfigured ipv4only.arpa zone on the recursive
servers would everything fail or would the devices just use the CLAT that
already exists?  Phones have CLAT for tethered devices.  Will they make the
A lookup with a IPv6-only ASN if the AAAA returns NOERROR/NODATA?

For wireline the routers are going to have to have CLAT support so there is
no needed to configure those routers with DNS64 servers.

While I think there are much better solutions than 464XLAT that is infinitely
better than DNS64/NAT64.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Nov 2017 13:11:24 +1300

On 14/11/2017 04:35, Philip Homburg wrote:
> DNSSEC is something that works today. 

This is not the impression I get from attending IEPG meetings
and chatting in the corridors at the IETF. Also, we knew throughout
the development of NAT64/DNS64 that DNSSEC was a major stumbling block.
I don't think it is a good idea to entangle RFC6434bis with that issue.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Nov 2017 13:11:46 +1300

On 14/11/2017 05:16, Philip Homburg wrote:
...
> For an application writer it is better to try to avoid doing the second pass.

I think there is a missing document, and it may well belong in v6ops not
6man: "IPv4 Applications on an IPv6-only Host". 

Your text above is probably a good summary of what the document needs
to cover. (I also suspect that if this document existed, we wouldn't need
Jordi's draft attempting to define "IPv6-only".)

   Brian

---

From: Ole Troan <[email-masked]>
Date: Tue, 14 Nov 2017 08:32:20 +0800

Mark,

> having to stuff up DNSSEC and have IPv6 connections terminate in IPv4 servers without

For the last point, that's no different than today's IP4 network where addresses change underneath you.

The scenario this thread is about, albeit the efforts in derailing it, is about an IPv6 only host (and application), connecting to something like the Internet. The premise of the experiment was "single stack".

There is therefore no CLAT in this scenario.

If you go back and look at my proposed host requirements, you'll see I added a requirement that hosts must be able to do the DNS64 function themselves, exactly for the reason of solving the DNSSEC problem with NAT64.
Now people here tell me that local validation of DNSSEC isn't done for IP4 either and in practice it's not deployable. I'd hope that's untrue, but regardless you don't appear to be in a worse position with DNS64 than you are without. Either you trust a distance recursive resolver to do the validation for you, or you do validation yourself (and also the synthesizing of IP6 addresses).

Cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 14 Nov 2017 08:34:15 +0800

Brian,

> I don't think it is a good idea to entangle RFC6434bis with that issue.

What's the DNSSEC major stumbling block?

Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 14 Nov 2017 08:37:40 +0800

Brian,

> 6man: "IPv4 Applications on an IPv6-only Host".

IPv4 applications do not run on an IPv6 only host, so that's a short document.

> Jordi's draft attempting to define "IPv6-only".)

Please take that to a different thread. This thread is about a IPv6 only, single stack host connecting to an IPv6 only network.
With a backdoor to the IPv4 Internet for legacy destinations.

Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Nov 2017 13:38:41 +1300

> What's the DNSSEC major stumbling block?

I pass. Try asking Geogg Huston, for example.

    Brian

---

From: Ole Troan <[email-masked]>
Date: Tue, 14 Nov 2017 09:03:46 +0800

Brian,

> I pass. Try asking Geogg Huston, for example.

As far as I understand it, DNSSEC has deployment issues, which are comparable for the DNS64 and non-DNS64 case.

https://tools.ietf.org/html/rfc6147#section-3
https://tools.ietf.org/html/rfc7050#section-3

But I will leave someone who knows DNS to give a definite answer to that.

If I understand what people are telling me correctly, your statement "major stumbling block" is not correct.

Best regards,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Nov 2017 14:33:06 +1300

> IPv4 applications do not run on an IPv6 only host, so that's a short document.

No, I don't think so. We haven't done a good job of advising implementers
in this area, and those apps will not go away spontaneously. Tweaking them
for the new world may be much easier than getting them rewritten, in terms
of the incentives in play.
> Please take that to a different thread.

Done ;-)

> This thread is about a IPv6 only, single stack host connecting to an IPv6 only network.

And that neglects the legacy that most such hosts have inside them.
I have a bunch in the host I'm typing on right now, which is connected
via NAT64 for the week.

    Brian

---

From: Ole Troan <[email-masked]>
Date: Tue, 14 Nov 2017 09:57:08 +0800

Brian,

[...]

> I have a bunch in the host I'm typing on right now, which is connected

I don't understand what you mean with the above.
I guess this is where we have to be extremely careful with terminology use.

If you are using the IPv6 only + NAT64 network you can't possibly use the legacy IPv4 only stuff in your laptop...?

Cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Nov 2017 15:01:02 +1300

> https://tools.ietf.org/html/rfc7050#section-3

My understanding during the BEHAVE discussions was that
the gymnastics required in the resolver code in a host
were considerably more complex in the NAT64/DNS64 case than
in any other.
 
> But I will leave someone who knows DNS to give a definite answer to that.

Yes, that would be very helpful.

> If I understand what people are telling me correctly, your statement "major stumbling block" is not correct.

It would be nice if you are correct.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Nov 2017 15:11:52 +1300

> If you are using the IPv6 only + NAT64 network you can't possibly use the legacy IPv4 only stuff in your laptop...?

Indeed. Because my laptop isn't providing a NAT46 bump in the stack, for example.

I haven't analysed this at all. What I'm saying is that we haven't done this;
we've simply sneered at application developers who haven't added IPPROTO_IPV6
to all their network code. Sneering doesn't solve much.

    Brian

---

From: Ole Troan <[email-masked]>
Date: Tue, 14 Nov 2017 10:17:17 +0800

Brian,

> to all their network code. Sneering doesn't solve much.

Gentle nudge?
I think Randy and Jen's experiment shows that we are nearly there.
On my iphone, where Apple enforced IPv6 support to be allowed to play, I only found _one_ single application that didn't work.
Even on my laptop, I had to look quite hard before finding something that broke.
We're nearly there!

Cheers,
Ole

---

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Nov 2017 21:47:26 -0500

Ca By <[email-masked]> wrote:
    > I have a network with 10s of millions of ipv6-only nodes, none of
    > which can so dnssec (neither android nor ios support it) and the
    > implication that these nodes are no longer ipv6 since they don't do
    > dnssec is ludicrous.

If you want to do DNSSEC validation, and there is a possibility of NAT64,
then you need to do the DNS64 locally.

If you aren't doing DNSSEC now, then it won't matter.
When you add DNSSEC, then you have to do NAT64 prefix discovery, and DNS64.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Ole Troan <[email-masked]>
Date: Tue, 14 Nov 2017 10:50:19 +0800

Michael,

> When you add DNSSEC, then you have to do NAT64 prefix discovery, and DNS64.

Could you speculate on how much of this should go in the host and thereby are candidates for host requirements and how much belongs in the application?

Best regards,
Ole

Btw: Your key has expired. ;-)

---

From: Philip Homburg <[email-masked]>
Date: Tue, 14 Nov 2017 11:44:32 +0100

> Now people here tell me that local validation
> of DNSSEC isn't done for IP4 either and in practice it's not
> deployable. I'd hope that's untrue, but regardless you don't appear
> to be in a worse position with DNS64 than you are without. Either
> you trust a distance recursive resolver to do the validation for
> you, or you do validation yourself (and also the synthesizing of
> IP6 addresses).

For quite a while now, I'm running two applications with local DNSSEC
validation on my laptop.

One is the cz.nic dnssec validator plugin for web browsers. The other is my
own code that uses getdns in ssh to validate SSHFP records.

In both cases, it just works. My conclusion is that wherever I take my laptop,
getdns can do local DNSSEC validation. DNSSEC works. Of course there are issues.
The fragmentation problems Geoff is seeing are real. But in practice it works.

One of the problems with DNSSEC and NAT64 is one way or another you have
to deal with a AAAA response that is not signed.

Without local synthesizing, local DNSSEC validation will fail. With local
synthesizing the local validator has to tell the application 'trust me, I
know what I'm doing'. Even if that's not actually true.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 14 Nov 2017 11:29:04 -0500

> Could you speculate on how much of this should go in the host and
    > thereby are candidates for host requirements and how much belongs in
    > the application?

You have to do this wherever you do DNSSEC.

That is seldom in the application.  There are libraries (e.g: libunbound)
so that clueful applications can do DNSSEC before the system is ready, but
this is rather akin to that some applications (ping/traceroute,etc) open
raw sockets and construct IP headers themselves.

So I'd say that it all goes into the host requirements.

    > Btw: Your key has expired. ;-)

finger [email-masked] | gpg --import

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 15 Nov 2017 00:40:25 +0800

On Tue, Nov 14, 2017 at 6:46 AM, Mark Andrews <[email-masked]> wrote:

> zone which allows CLAT to get its mapping.  All the phones have CLAT
> support.

That's an interesting idea. It would work in theory, but such a network
would completely break devices that don't support 464xlat. That gives up
one of the major advantages of NAT64/DNS64, which is that it's a 90%
solution even just by itself - yes, IPv4-only applications and address
literals exist, but most simple client/server applications Just Work behind
it.

It's not true that all phones have clat support. Notably, Apple not only
does not support it but appears ideologically opposed to it on the grounds
that it does not have a good exit strategy (because it makes it possible to
run IPv4-only apps forever).

---

From: Mark Andrews <[email-masked]>
Date: Wed, 15 Nov 2017 11:06:33 +1100

> On 15 Nov 2017, at 3:40 am, Lorenzo Colitti <[email-masked]> wrote:
> 
> zone which allows CLAT to get its mapping.  All the phones have CLAT support.
> 
> That's an interesting idea. It would work in theory, but such a network would completely break devices that don't support 464xlat. That gives up one of the major advantages of NAT64/DNS64, which is that it's a 90% solution even just by itself - yes, IPv4-only applications and address literals exist, but most simple client/server applications Just Work behind it.

And that 90% “solution” has lots of down sides.  It basically requires EVERY DNS VALIDATOR ON
THE PLANET TO SUPPORT DNS64 JUST IN CASE IT IS USED BEHIND A DNS64 SERVER.

DNS64/NAT64 was presented as NOT REQUIRING node changes when first mooted.  It keeps on
requiring more and more highly invasive node changes to support.  It was from the very beginning
bad engineering.   To get IPv4 as a service some node changes are required.  Lets make sure they
are MINIMAL ones.

Just for the record DNSSEC validators need to send BOTH CD=0 and CD=1 queries to get answers
though a upstream VALIDATING server which includes a VALIDATING DNS64 server as CD=0 and
CD=1 address different DNSSEC threats.  I tried very hard to point that out when RFC 6147 was
being written but the working group decide that CD indicated whether the client was validating or
not.  There is NO SUCH INDICATION in a DNS message.

  If a query arrives at a vDNS64 device with the "Checking Disabled"
   (CD) bit set, it is an indication that the querying agent wants all
   the validation data so it can do checking itself.  By local policy,
   vDNS64 could still validate, but it must return all data to the
   querying agent anyway.

CD=0 queries causes the upstream validating servers to reject incoming spoofed answers
or stale answers (this is a common operational problem).

CD=1 queries allow the validation to succeed when the upstream validator has a bad trust
anchor or a bad clock which is rejecting legitimate answers.

A validating client can’t just send CD=1 queries as the upstream validator doesn’t kick in.
The upstream validator can lock onto a stale answer source.  It needs to send CD=0 queries
on validation failure to force the upstream validator to try multiple sources.

A validating client can’t just send CD=0.  It needs to send CD=1 on SERVFAIL in case the
upstream validator has a bad trust anchor (likely with the upcoming root KSK roll) or has
a bad clock (these usually get fixed fast).

Now to get a answer from a signed zone with servers with stale answers a validatiing DNS64 client
needs to send:

a) send CD=1 and validation failure send CD=0 then on AAAA validation failure send CD=1 and
    hope the TTL was not 0 and that is not cachable and there is no assurance that you won’t get
    a answer from a stale source.

	or

b) send CD=0 and on validation failure of the AAAA send CD=1 and hope the TTL was not 0 as
    that is not cachable and there is no assurance that you won’t get a answer from a stale source.

TTL=0 answers exist.

Note none of this is documented in a RFC.  You have to understand how both DNSSEC and DNS64 work to
realise this.

IPV4ONLY.ARPA is currently has a secure delegation which breaks prefix discover for DNS VALIDATORS.
Note “ad” is set in the flags.  Yes, I’ve submitted a errata.  Yes, I’ve opened a ticket to get it fixed but
based on past experience that could take months if it happens at all.  You will note that the recursive
server is running on the loopback interface so all DNS answers are being validated here.

[rock:bind9/bin/named] marka% dig IPV4ONLY.ARPA
;; BADCOOKIE, retrying.

; <<>> DiG 9.12.0b2+hotspot+add-prefetch+marka <<>> IPV4ONLY.ARPA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8504
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 7dbf8beb79be47a09eb5313d5a0b776f4fae3aa6931d9583 (good)
;; QUESTION SECTION:
;IPV4ONLY.ARPA.			IN	A

;; ANSWER SECTION:
ipv4only.arpa.		26574	IN	A	192.0.0.171
ipv4only.arpa.		26574	IN	A	192.0.0.170

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Nov 15 10:08:31 AEDT 2017
;; MSG SIZE  rcvd: 115

[rock:bind9/bin/named] marka% 

> It's not true that all phones have clat support. Notably, Apple not only does not support it but appears ideologically opposed to it on the grounds that it does not have a good exit strategy (because it makes it possible to run IPv4-only apps forever).

---

From: Ole Troan <[email-masked]>
Date: Wed, 15 Nov 2017 10:07:52 +0800

Mark,

Thanks for doing the analysis of this. It will take me some time to digest.

If I may try to suggest a solution based on what you are saying:

- Remove (external) DNS64 from the solution
- Replace NAT64 prefix discovery with some sort of local configuration. e.g. put it in DHCP or RA

Which has the implications that:
 - host learns NAT64 prefix via RA/DHCP
 - host is free to use whatever DNS recursive resolvers (instead of the must be local (and on correct interface where the NAT64 is) resolver
 - host synthesises addresses itself. And does validation before synthesising (if that's required).

Is this the solution you would be looking for?

And yes, you need host changes. But we need that anyway.

Cheers,
Ole

> On 15 Nov 2017, at 08:06, Mark Andrews <[email-masked]> wrote:
> 
>

---

From: Ca By <[email-masked]>
Date: Wed, 15 Nov 2017 02:34:40 +0000

On Tue, Nov 14, 2017 at 6:08 PM Ole Troan <[email-masked]> wrote:

>  - host is free to use whatever DNS recursive resolvers (instead of the
> must be local (and on correct interface where the NAT64 is) resolver

Or your peer node could deploy ipv6 and be done with all these transition
nonsense.

As has been reported in elsewhere, docsis and 3gpp networks see 50+ and
70+% of their bits moved to ipv6.   The problem size is waning quickly,
especially on modern OS

> >> It's not true that all phones have clat support. Notably, Apple not
> only does not support it but appears ideologically opposed to it on the
> grounds that it does not have a good exit strategy (because it makes it
> possible to run IPv4-only apps forever).
> >
> >
> > --
> > Mark Andrews, ISC

---

From: Jen Linkova <[email-masked]>
Date: Wed, 15 Nov 2017 14:05:18 +1100

> And yes, you need host changes. But we need that anyway.

NAT64 is a band aid, a tactical solution to deal with IPv4-only hosst
while we are waiting for them to die. Requiring *mandatory* changes on
majority of devices which are working on NAT64 networks just fine
currently to solve problems for those who either a) sign their zones
but do not enable Ipv6 b)doing some smart things in their host
resolvers looks like an overkill to me..

IMHO the optimal solution is:
- the network SHOULD provide a host with NAT64 prefix information in
RA (I do not believe that information needs to be duplicated in DHCP
at all);
- an application MAY use that information to do AAAA synthetics
(validating resolvers SHOULD do that).
- network still provides DNS64 servers to hosts so all unsophisticated
hosts (majority of devices falls into that category) continue to use
network-provided resolvers.

-- 
SY, Jen Linkova aka Furry

---

From: Erik Kline <[email-masked]>
Date: Wed, 15 Nov 2017 04:14:49 +0000

Actually, I think the think we should is add the following to the PvD info:

    [1] NAT64 prefix
    [2] set of separate DNS64 servers, for clients who don't yet do
client-side DNS64 synthesis.

Unfortunately, it's too early to create a SHOULD/MUST that IPv6 hosts
support PvDs, but I think we'll just need to revisit that in the
future.

---

From: Jen Linkova <[email-masked]>
Date: Wed, 15 Nov 2017 15:24:16 +1100

> client-side DNS64 synthesis.

I love that idea.
Even better than RA/DHCP ;)

> support PvDs, but I think we'll just need to revisit that in the

Well, we are talking about hosts/applications which do not  exist anyway.
So basically if an application wants to know about NAT64 prefix and
the presence of DNS64,
we need to define a mechanism to provide that information. PvD sounds
like a right place to do it.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 15 Nov 2017 15:36:28 +0800

Thanks.

[Jordi] What I mean is a LAN (which is dual-stack) but with *hosts* that are IPv4-only (old devices, IP cameras, printers, many other very frequently found in home networks, even corporate ones). The problem I see is that those hosts not always will get updated, unless maybe very severe security issues …

[Jordi] yeah, I guess we agree …
    
    Cheers,
    Ole

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 15 Nov 2017 15:52:32 +0800

[Jordi] The problem I see here is that in both home and enterprise networks, for at least 3-4 years, we will have to support IPv4 only devices (as just mention in a previous email). So NAT64 is not sufficient.

    :-)
    
    Cheers,
    Ole

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 15 Nov 2017 15:57:27 +0800

That tunneling technology is 464XLAT, depending on how you deploy it:

https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-deployment/

Regards,
Jordi

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 15 Nov 2017 16:06:06 +0800

[Jordi] Mark, this will not work: You need to consider that even if the phone is dual stack, there may be IPv4-only devices behind the phone (tethering), that NEED a DNS64. If the IPv4 device is validating, then is broken. If the IPv4 devices is not validating, then because the phone act as DHCP server for it, and provides the DNS, the phone acts as the DNS64 and even validator, then we are set … but phones today don’t do DNSSEC.

    Mark

---

From: Mark Andrews <[email-masked]>
Date: Wed, 15 Nov 2017 21:17:32 +1100

> On 15 Nov 2017, at 7:06 pm, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 

and the IPv4 device sends a IPv4 packet to the phone which then runs it through the CLAT to
translate it into a IPv6 packet which is sent to the NAT64 which turns it back into a IPv4 packet.
None if this requires a DNS64 server.   All DNS64 does is reduce the number of IPv4 packets
that are translated by the CLAT.  It does not reduce the work of the NAT64.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Nov 2017 23:24:29 +1300

Excuse front posting but +1, this is IMHO just about the
last thing worth saying on this thread.

Regards
   Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 15 Nov 2017 18:50:22 +0800

[Jordi] Yeah, sorry, I guess I’m too sleepy today and I’ve interpreted something else. In fact, I’ve a specific section about that in my document (3.  Using 464XLAT with/without DNS64):

https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-deployment

---

From: <[email-masked]>
Date: Wed, 15 Nov 2017 13:35:30 +0000

Hi Jen,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : ipv6 [mailto:[email-masked]] De la part de Jen Linkova
> Envoyé : mercredi 15 novembre 2017 04:05
> À : Ole Troan
> Cc : 6man WG; Mark Andrews
> Objet : Re: IPv6 only host NAT64 requirements?
> 

[Med] Please check: https://tools.ietf.org/html/rfc7051#section-5.7.3 

Things may get complex if multiple NSPs are used for load-balancing or if destination based NAT64s are deployed. A list of issues is elaborated in https://tools.ietf.org/html/rfc7225#section-3.1 

> >>> That's an interesting idea. It would work in theory, but such a
> network would completely break devices that don't support 464xlat. That
> gives up one of the major advantages of NAT64/DNS64, which is that it's a
> 90% solution even just by itself - yes, IPv4-only applications and address
> literals exist, but most simple client/server applications Just Work
> behind it.
> >>

---

From: james woodyatt <[email-masked]>
Date: Wed, 15 Nov 2017 11:07:53 -0800

On Nov 14, 2017, at 19:05, Jen Linkova <[email-masked]> wrote:
> - the network SHOULD provide a host with NAT64 prefix information in RA;

Disagree. If the network has NAT64, then it should deploy RFC 7225. Ye gods, this is the very last thing that should be jammed into RA messages.

>  (I do not believe that information needs to be duplicated in DHCP at all)

Totally agree about that.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: Ole Troan <[email-masked]>
Date: Thu, 16 Nov 2017 05:47:13 +0800

James,

> Disagree. If the network has NAT64, then it should deploy RFC 7225. Ye gods, this is the very last thing that should be jammed into RA messages.

Do we really want PCP in IPv6?
Is PCP successful in IPv4? Or does it even work well with A+P based solutions?

> Totally agree about that.

Appears this isn't as simple a problem as I thought. Let me read 7051 in it's excruciating detail.

Guess we're stuck.

Best regards,
Ole

---

From: james woodyatt <[email-masked]>
Date: Wed, 15 Nov 2017 15:04:21 -0800

> Do we really want PCP in IPv6?

If we have any kind of NAT, then we need PCP. Using NAT without PCP considered harmful. That goes for NAT64 and NAT66.

> Is PCP successful in IPv4?

Well, there was this: <https://www.ietf.org/proceedings/88/slides/slides-88-pcp-5.pdf <https://www.ietf.org/proceedings/88/slides/slides-88-pcp-5.pdf>>

> Or does it even work well with A+P based solutions?

Designed expressly for it.

---

From: Ole Troan <[email-masked]>
Date: Thu, 16 Nov 2017 07:24:51 +0800

James,

> If we have any kind of NAT, then we need PCP. Using NAT without PCP considered harmful. That goes for NAT64 and NAT66.

It's not for the lack of trying that IPv6 isn't adopted everywhere.
As IPv4 address sharing ratio's increase, say good bye to endpoint independent NATs, IP fragmentation...

But now I have to first implement a PCP client, discover the PCP server address, and then finally get the NAT64 prefix. ;-)

> Well, there was this: <https://www.ietf.org/proceedings/88/slides/slides-88-pcp-5.pdf>
> 

Ah, yes so it does.
Doesn't work well with address and port dependent filtering though.

Cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Nov 2017 12:36:37 +1300

> If we have any kind of NAT, then we need PCP. Using NAT without PCP considered harmful. That goes for NAT64 and NAT66.

I have a more practical view. We can't assume that IPv6 hosts
grok DHCPv6, and we can't assume they grok PCP. We know that they
grok RAs, although of course they need an update to grok a new
option. So it seems to me that there isn't much doubt about the
need for an RA based solution.

    Brian

---

From: james woodyatt <[email-masked]>
Date: Wed, 15 Nov 2017 16:13:08 -0800

On Nov 15, 2017, at 15:36, Brian E Carpenter <[email-masked]> wrote:
> option.

Simplifying... hosts need an update, and the question we have had on the table for four years now is what update to push. What if answers were something people wanted to read?

> So it seems to me that there isn't much doubt about the

It seems to me that, of the various solutions analyzed by RFC 7051, that particular one comes with a raft of problems, which were the reasons we have RFC 7225 now.

	<https://tools.ietf.org/html/rfc7051#section-5.7 <https://tools.ietf.org/html/rfc7051#section-5.7>>

---

From: Ca By <[email-masked]>
Date: Thu, 16 Nov 2017 00:16:18 +0000

On Wed, Nov 15, 2017 at 4:13 PM james woodyatt <[email-masked]> wrote:

> Disagree. If the network has NAT64, then it should deploy RFC 7225. Ye
> gods, this is the very last thing that should be jammed into RA messages.
>
>
> If we have any kind of NAT, then we need PCP. Using NAT without PCP
> considered harmful. That goes for NAT64 and NAT66.
>
>
> Simplifying... hosts need an update, and the question we have had on the
> table for four years now is what update to push. What if answers were
> something people wanted to read?
>
> It seems to me that, of the various solutions analyzed by RFC 7051, that
> particular one comes with a raft of problems, which were the reasons we
> have RFC 7225 now.
>
> <https://tools.ietf.org/html/rfc7051#section-5.7>
>
>
> --james woodyatt <[email-masked]>
>
>
I may be missing the point, but we talking about updating host (5 year time
horizon) to solve the corresponding node not supporting ipv6?

Maybe we just need to cite this more and do nothing more

https://tools.ietf.org/html/bcp177

In short, to be on the internet you need to support ipv6.

What problem does this not solve ?

---

From: james woodyatt <[email-masked]>
Date: Wed, 15 Nov 2017 16:28:22 -0800

> But now I have to first implement a PCP client, discover the PCP server address, and then finally get the NAT64 prefix. ;-)

Having implemented a PCP client, I can say from experience that it is a lot easier than implementing a DHCPv6 client.

Oh, and you have to discover all the PCP server addresses (in addition to the PCP server anycast address by RFC 7723) before you can use RFC 7225 to discover the NAT64 network-specific prefix (NSP) for each one. If you’re really married to DHCPv6, then I suppose you could use RFC 7291 for that. But if you want to add those data to RA messages too, why not? (Oh right, I remember why not: because it’s a bad idea. Just use the anycast address.)

> Doesn't work well with address and port dependent filtering though.

Is there a reason you think <https://tools.ietf.org/html/rfc6887#section-13.3 <https://tools.ietf.org/html/rfc6887#section-13.3>> doesn’t work well? Seemed to work well when I implemented it.

---

From: <[email-masked]>
Date: Thu, 16 Nov 2017 07:28:38 +0000

Hi Ole, 

Please see inline. 

Cheers,
Med

> De : ipv6 [mailto:[email-masked]] De la part de Ole Troan
> Envoyé : mercredi 15 novembre 2017 22:47
> À : james woodyatt
> RA;

[Med] IPv6 Firewalls, NAT64, and NPTv6 are target use cases for PCP. All those were taken into account when designing PCP. 

> Is PCP successful in IPv4?

[Med] PCP is a deployment reality. Most of CGN vendors are implementing PCP. 

 Or does it even work well with A+P based
> solutions?

[Med] Why do you want PCP for A+P? 

Please remember that we have indicated the following in draft-ietf-softwire-stateless-4v6-motivation: 

====
3.1.4.  No Additional Protocol for Port Control is Required

   Stateless solutions do not require activating a new dynamic signaling
   protocol in the end-user CPE in addition to those already used.  In
   particular, existing protocols (e.g., UPnP IGD:2 [UPnP-IGD]) can be
   used to control the NAT mappings in the CPE.

      Note: To overcome some security concerns, IGD:2 authorization
      framework [UPnP-IGD] should be used and security considerations
      elaborated in [Sec_DCP] should be taken into account.
====

---

From: <[email-masked]>
Date: Thu, 16 Nov 2017 07:29:44 +0000

Ole, 

Please see inline. 

Cheers,
Med

> Envoyé : jeudi 16 novembre 2017 00:25
> À : james woodyatt
> But now I have to first implement a PCP client, discover the PCP server
> address, and then finally get the NAT64 prefix. ;-)

[Med] This is more subtle. You don't need to implement PCP to discover NAT64 prefixes, but because of other NAT64 problems (e.g., allow for incoming connection, referrals, reduce keepalive messages, etc.) PCP is your friend. In such case, prefix discovery using PCP is more determinist compared to the heuristic (there are also many other issues unsolved when using the heuristic). 

My take on this is this wording from RFC7849:

==
   C_REC#7:  In order to ensure IPv4 service continuity in an IPv6-only
             deployment context, the cellular host should support a
             method to learn PREFIX64(s).

                ...

                In environments based on the Port Control Protocol
                (PCP), cellular hosts should follow [RFC7225] to learn
                the IPv6 Prefix used by an upstream PCP-controlled NAT64
                device.  If PCP is not enabled, the cellular host should
                implement the method specified in [RFC7050] to retrieve
                the PREFIX64.
==

> > Well, there was this:
> <https://www.ietf.org/proceedings/88/slides/slides-88-pcp-5.pdf>
> >

---

From: Tim Chown <[email-masked]>
Date: Thu, 16 Nov 2017 09:51:47 +0000

Hi,

> On 15 Nov 2017, at 23:04, james woodyatt <[email-masked]> wrote:
> 

And PCP is still needed to negotiate firewall holes in a pure IPv6 scenario, isn’t it?  Assuming the host with PCP is behind Simple Security.

A question: is this something we should conducer for RFC6434-bis, or should we be silent on PCP?

> Designed expressly for it.

I assumed PCP was designed with an eye firmly on future routed home networks where firewall holes need to be opened. What is the alternative?

Tim

---

From: Ca By <[email-masked]>
Date: Thu, 16 Nov 2017 12:42:01 +0000

On Thu, Nov 16, 2017 at 1:53 AM Tim Chown <[email-masked]> wrote:

> And PCP is still needed to negotiate firewall holes in a pure IPv6
> scenario, isn’t it?  Assuming the host with PCP is behind Simple Security.
>

No

> > Well, there was this: <
> https://www.ietf.org/proceedings/88/slides/slides-88-pcp-5.pdf>
> >
> I assumed PCP was designed with an eye firmly on future routed home
> networks where firewall holes need to be opened. What is the alternative?
>

The alternative is secure host and no firewall. There is no firewall at the
ietf conference right now, right?  Are you secure ? Is there a malware
outbreak?

The fatal flaw in PCP (aside from the name) is that it assumes the host
needs protection yet it gives the host the power to control the firewall.
Next gen malware will come via email (just like today), it will encrypt
your hard drive, and then setup and c2 network on your pc via pcp
controls.  Sad!

CB

---

From: Tim Chown <[email-masked]>
Date: Thu, 16 Nov 2017 15:26:44 +0000

> On 16 Nov 2017, at 12:42, Ca By <[email-masked]> wrote:
> 
> The alternative is secure host and no firewall. There is no firewall at the ietf conference right now, right?  Are you secure ? Is there a malware outbreak?

Yet in practice pretty much every ISP deploying IPv6 to residential is doing so with RFC 6092, or stricter. Perhaps with a toggle to turn off firewalling, but that’s the reality.

OTOH it seems that PCP support in hosts / CPEs isn't exactly widespread.

> The fatal flaw in PCP (aside from the name) is that it assumes the host needs protection yet it gives the host the power to control the firewall.  Next gen malware will come via email (just like today), it will encrypt your hard drive, and then setup and c2 network on your pc via pcp controls.  Sad!

True, and that happens with UPnP today...

Tim

---

From: Ca By <[email-masked]>
Date: Thu, 16 Nov 2017 18:26:35 +0000

On Thu, Nov 16, 2017 at 7:26 AM Tim Chown <[email-masked]> wrote:

> > >>> Disagree. If the network has NAT64, then it should deploy RFC 7225.
> Ye gods, this is the very last thing that should be jammed into RA messages.
> > >>
> > The alternative is secure host and no firewall. There is no firewall at
> the ietf conference right now, right?  Are you secure ? Is there a malware
> outbreak?
>
> Yet in practice pretty much every ISP deploying IPv6 to residential is
> doing so with RFC 6092, or stricter. Perhaps with a toggle to turn off
> firewalling, but that’s the reality.
>

Yes, security FUD marketing is very real

Speaking for one largish mobile network ipv6 deployment, we have not hand
any issues related to lack of stateful traffic inspection in the last 4
years of ipv6 deployment. So if we are doing a science experiment, we have
a control group which has faired the same as the experimental group.

I will accept landlines are a slightly different animal.

---

From: james woodyatt <[email-masked]>
Date: Thu, 16 Nov 2017 12:06:43 -0800

On Nov 16, 2017, at 07:26, Tim Chown <[email-masked]> wrote:
>> I assumed PCP was designed with an eye firmly on future routed home networks where firewall holes need to be opened. […]

It was. In fact, that was the reason NAT-PMP evolved into PCP in the first place: because we needed to extend NAT-PMP to support punching holes in RFC 6092 firewalls.

>> The alternative is secure host and no firewall. There is no firewall at the ietf conference right now, right?  Are you secure ? Is there a malware outbreak?

That’s the alternative, but it’s not the dominant practice.

> Yet in practice pretty much every ISP deploying IPv6 to residential is doing so with RFC 6092, or stricter. Perhaps with a toggle to turn off firewalling, but that’s the reality.

Surveys I’ve seen show that most IPv6 residential networks outside of a few large providers in USA are using something like RFC 6092 with no prior user action. Home users either have no option to disable the firewall or they have no knowledge of it. Anybody planning to deploy IPv6 applications in residential networks (and I’m absolutely one of them) would be absolutely stupid to expect any way for passive listeners to receive inbound flows from arbitrary remote endpoints. Both REC-48 and REC-49 in RFC 6092 are widely ignored in the field. (Which is the outcome I warned against when I was writing it.)

> OTOH it seems that PCP support in hosts / CPEs isn't exactly widespread.

Is there support in FreeBSD, Linux or Windows? I don’t think so.

> True, and that happens with UPnP today…

UPnP has the added festival of third-party option enabled by default. It’s truly a magical wonder.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 16 Nov 2017 15:48:54 -0500

I thought we need PCP in order to enable any kind of incoming connections in
the home.

The default security of rfc7084 section 4.5, which recommends using RFC6092:

              Recommended Simple Security Capabilities in
                 Customer Premises Equipment (CPE) for
              Providing Residential IPv6 Internet Service

denied incoming TCP SYN packets, although I can't find the exact sentence
right now.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Thu, 16 Nov 2017 15:51:42 -0500

> should we be silent on PCP?

I think that we should mention PCP.
I don't know whether to write MAY, SHOULD or MUST.
Probably not MUST.

BTW: Is there any RA option to signal that PCP might be needed?

---

From: james woodyatt <[email-masked]>
Date: Thu, 16 Nov 2017 14:03:06 -0800

> I don't know whether to write MAY, SHOULD or MUST.

Given that discovering all the relevant PCP servers is potentially impossible without a DHCPv6 client, and those are not explicitly RECOMMENDED, I think the only reasonable option here is "MAY implement a PCP client” and not “SHOULD” or “MUST” to implement a PCP client.

> BTW: Is there any RA option to signal that PCP might be needed?

The O flag can signal that RFC 7291 may be required to discover any additional PCP servers beyond the one that can be available at 2001:1::1.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 17 Nov 2017 09:26:06 +1100

> On 17 Nov 2017, at 7:06 am, james woodyatt <[email-masked]> wrote:
> 

Then those ISP’s are delivering a broken Internet connection to their customers.

There is a significant customer base that configure their border routers to allow
incoming connections today.  The ability to do this is built into retail routers today.
Customers that need this ability don’t buy routers that don’t support it.

Personally I would prefer that a router just did anti spoofing filtering and nothing else by
default but that wasn’t the consensus.   Allow only allocated source addresses out
the north interface.  Block allocated source addresses in on the north interface.  This
stops compromised internal machines successfully spoofing someone else.   The
also prevents someone else using spoofed address you are using coming in at the
cost of not being able to send a source routed packet to yourself.

Mark

---

From: <[email-masked]>
Date: Fri, 17 Nov 2017 06:52:51 +0000

Hi Michael, 

For the particular case of NAT64, this requirement from RFC6888 applies: 

   REQ-9:  A CGN MUST implement a protocol giving subscribers explicit
      control over NAT mappings.  That protocol SHOULD be the Port
      Control Protocol [RFC6887].

I'm not aware of any requirement for the LAN. The only recommendation I'm aware of is on the WAN interface of an IPv6 CPE:

   W-6:  The WAN interface of the CE router SHOULD support a Port
         Control Protocol (PCP) client as specified in [RFC6887] for use
         by applications on the CE router.  The PCP client SHOULD follow
         the procedure specified in Section 8.1 of [RFC6887] to discover
         its PCP server.  This document takes no position on whether
         such functionality is enabled by default or mechanisms by which
         users would configure the functionality.  Handling PCP requests
         from PCP clients in the LAN side of the CE router is out of
         scope.

Cheers,
Med

> De : ipv6 [mailto:[email-masked]] De la part de Michael Richardson
> Envoyé : jeudi 16 novembre 2017 21:49
> À : 6man WG

---

From: Jen Linkova <[email-masked]>
Date: Fri, 17 Nov 2017 19:30:33 +1100

> [Med] Please check: https://tools.ietf.org/html/rfc7051#section-5.7.3

Thanks for pointing this out. To be honest I disagree with what that
section says.
I'm trying to refrain from participating  'SLAAC vs DHCPv6' so I will
not mention all those issues with multihoming for example but....
If you are saying that the prefix should not be distributed via RAs
because it needs to be configured on routers, then what about DNS
servers and SLAAC prefixes themselves?
There are SLAAC-only networks out there while RFC7934 does not
recommend DHCPv6 as the only way to configure clients.
So between those two RA does look like a better way.

> Things may get complex if multiple NSPs are used for load-balancing or if destination based NAT64s are deployed. A list of issues is elaborated in https://tools.ietf.org/html/rfc7225#section-3.1

It's more like v6ops question but I'm really curious if multiple
prefixes scenario is real.
RA option might contain multiple prefixes anyway.

---

From: Fred Baker <[email-masked]>
Date: Fri, 17 Nov 2017 16:38:02 +0800

Tore Anderson has a multiple prefix installation.

Sent using a machine that autocorrects in interesting ways...

> On Nov 17, 2017, at 4:30 PM, Jen Linkova <[email-masked]> wrote:
>

---

From: Fred Baker <[email-masked]>
Date: Fri, 17 Nov 2017 16:47:02 +0800

To be very honest, situations like Tore’s have always made me question the wisdom of a special prefix for IPv4/IPv6 NAT. One is communicating with a peer at an IPv6 address. One got the address because the initiating SYN-or-whatever came from it, or the address was provided in DNS. Tomorrow, with any luck, it will be a native address; today, it is a /96 embedded in a /64, one of many /64s in the network.

Why should I know or care that the path to the peer has a NAT in it? Yes, there are some end to end session assumptions that fail. No matter what I do, they will fail. I at least have as good connectivity as I would have in an IPv4 network.

> On Nov 17, 2017, at 4:38 PM, Fred Baker <[email-masked]> wrote:
>

---

From: <[email-masked]>
Date: Fri, 17 Nov 2017 08:47:44 +0000

Hi Jen, 

Please see inline. 

Cheers,
Med

> De : Jen Linkova [mailto:[email-masked]]
> Envoyé : vendredi 17 novembre 2017 09:31
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Ole Troan; 6man WG; Mark Andrews

[Med] I also disagree with many of the points in RFC7051, but that is the document which reflects the IETF consensus on learning prefix64s. 

We had many opportunities in the past to ignore the recommendations in RFC7051, but we didn't. For example, RFC8115 says the following: 

==
   Note that it was tempting to define three distinct DHCPv6 options,
   but that approach was not adopted because it has a side effect: the
   specification of a DHCPv6 option that could be used to discover
   unicast Prefix64s in environments where multicast is not enabled.
   Such a side effect conflicts with the recommendation to support the
   Well-Known DNS Name heuristic discovery-based method for unicast-only
   environments (Section 6 of [RFC7051]).
==

> So between those two RA does look like a better way.

[Med] It is evident that RA-based approach may be a good candidate for some deployments. Others may argue that another solution is appropriate for their deployment, and so on. 

> 
> > Things may get complex if multiple NSPs are used for load-balancing or
> if destination based NAT64s are deployed. A list of issues is elaborated
> in https://tools.ietf.org/html/rfc7225#section-3.1
> 

[Med] Indeed. It is already ACKed in 7051: 

   Note: If the RA would include multiple NSPs, Issue #5 could be solved
   as well, but only if nodes as a group would select different NSPs,
   hence supporting load balancing.  As this is not clear, this item is
   not yet listed under PROs or CONs.

> >> >>> Is there any reason to run DNS64 at all these days?  ipv4only.arpa
> can
> >> be a preconfigured
> CLAT
> >> >> And that 90% “solution” has lots of down sides.  It basically
> requires
> >> EVERY DNS VALIDATOR ON
> >> >> Just for the record DNSSEC validators need to send BOTH CD=0 and
> CD=1
> >> queries to get answers
> >> >> though a upstream VALIDATING server which includes a VALIDATING
> DNS64
> >> server as CD=0 and
> >> >> CD=1 address different DNSSEC threats.  I tried very hard to point
> that
> >> out when RFC 6147 was
> >> >> CD=0 queries causes the upstream validating servers to reject
> incoming
> >> spoofed answers
> >> >> The upstream validator can lock onto a stale answer source.  It
> needs
> >> to send CD=0 queries
> >> >> on validation failure to force the upstream validator to try
> multiple
> >> sources.
> >> >>
> >> >> Now to get a answer from a signed zone with servers with stale
> answers
> >> a validatiing DNS64 client
> >> >> needs to send:
> >> >>
> >> >> a) send CD=1 and validation failure send CD=0 then on AAAA
> validation
> >> failure send CD=1 and
> >> >> b) send CD=0 and on validation failure of the AAAA send CD=1 and
> hope
> >> the TTL was not 0 as
> >> >>    that is not cachable and there is no assurance that you won’t get
> a
> >> >> Note none of this is documented in a RFC.  You have to understand
> how
> >> both DNSSEC and DNS64 work to
> >> >> realise this.
> >> >>
> >> >> IPV4ONLY.ARPA is currently has a secure delegation which breaks
> prefix
> >> discover for DNS VALIDATORS.
> >> >> based on past experience that could take months if it happens at
> all.
> >> You will note that the recursive

---

From: Ole Troan <[email-masked]>
Date: Fri, 17 Nov 2017 17:19:46 +0800

Med,

Thanks for all the references. Seems like most bases have been covered here. ;-)

For the IETF NAT64 IMHO I need:
 - No dependency on DNS64. Want to use recursive resolver I trust plus local validating resolver.
 - Not depend on the success of PCP for NAT64 prefix discovery
 - If the host couldn't learn the NAT64 prefix any other way, I suppose it could throw an ICMP echo towards
   64:ff9b::127.0.0.1 (or perhaps just 64:ff9b::)

But I also see there being different deployment options here.
Btw, for multiple NSPs, couldn't you partly solve that by injecting more specifics into routing?

Cheers,
Ole

> On 17 Nov 2017, at 16:47, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Jen,
> 
> Please see inline.
> 
> Cheers,
> Med
>

---

From: Tim Chown <[email-masked]>
Date: Fri, 17 Nov 2017 16:12:17 +0000

Hi,

> On 16 Nov 2017, at 22:03, james woodyatt <[email-masked]> wrote:
> 

Yes, if we were to add something, I agree from comments made that MAY is the strongest we should use. 

But as you say, with lack of support in common OSes, it’s somewhat moot at present.  

Tim

---

From: james woodyatt <[email-masked]>
Date: Fri, 17 Nov 2017 10:20:13 -0800

On Nov 16, 2017, at 22:52, [email-masked] wrote:
> I'm not aware of any requirement for the LAN. […]

It’s a recommendation in RFC 6092. There is a whole section about it.

  <https://tools.ietf.org/html/rfc6092#section-3.4 <https://tools.ietf.org/html/rfc6092#section-3.4>>

It doesn’t mention PCP explicitly because RFC 6092 predates the creation of the PCP working group. It recognized that A) there was no standard to protocol to recommend, and B) it was necessary to recommend the deployment of something non-standard until there is a standard available. Hence, the strangeness of section 3.4 and the text of the included recommendation.

                                          Until a consensus emerges
 around a specific method, the following recommendations are the best
 guidance available.

   REC-48: Internet gateways with IPv6 simple security capabilities
   SHOULD implement a protocol to permit applications to solicit inbound
   traffic without advance knowledge of the addresses of exterior nodes
   with which they expect to communicate.

It would probably be a good idea to revise RFC 6092 to explicitly recommend PCP here.

---

From: Jen Linkova <[email-masked]>
Date: Sat, 18 Nov 2017 20:22:24 +1100

> Disagree. If the network has NAT64, then it should deploy RFC 7225.

Even if does not deploy it for NAT44? Do we really want to make NAT64
deployments more complicated than
just replacing NAT44 with NAT64? ;)

---

From: Fernando Gont <[email-masked]>
Date: Sat, 18 Nov 2017 20:18:26 +0800

> But as you say, with lack of support in common OSes, it’s somewhat moot at present.  

100% agreed. But at the same time, that's circular reasoning ;-)

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 19 Nov 2017 08:40:18 +1300

> just replacing NAT44 with NAT64? ;)

IMHO, no. Also, I don't believe that "should deploy RFC 7225" is
documented anywhere as a normative requirement.

To be clear: I used ietf-nat64 all week, and all the things that didn't work
are not an issue on a dual-stack network. From the host's point of view,
dual-stack is definitively superior, IMNSHO, and nothing is going to
change that. NAT64 is second-best. It may appear to be cheaper for some
operators in some scenarios, that's all. 

    Brian

---

From: Ole Troan <[email-masked]>
Date: Sun, 19 Nov 2017 02:03:23 +0100

Brian,

> operators in some scenarios, that's all.

From that perspective, "IPv4 only" is still best. But that's not where we want to be, is it?

The original transition plan was for all networks, hosts and application to be dual-stacked, then when that point was reached, there would be no more traffic on the "IPv4 Internet" and it could be turned off. We now know that this point is not within sight.

Dual-stack as a transition is a failure. Dual-stack is a deployment model where we bear the cost caused by the IPv4 laggards.

IPv6 only + NAT64 is progress. It relegates IPv4 to the edges.
We want a situation where IPv4 only services are fronted by IPv6, and the cost born by those operating those services.

The challenge we have in front of us is to make IPv6 only work.

Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 19 Nov 2017 10:45:27 +0100 (CET)

> The challenge we have in front of us is to make IPv6 only work.

When I speak to vendors about this, I get different answers. Some are 
saying "nobody will deploy IPv6 only, so why should I make changes in my 
desktop OS to support it for legacy applications?"

And I imagine any access provider will say "I can't deploy IPv6 only, 
because it'll break a lot of applications that people are using on desktop 
OSes".

So this is classic catch 22.

This was fixed on Android by throwing up hands and giving up on IPv6 only, 
and just installing CLAT on it to make sure most legacy applications just 
work.

On iOS it was fixed by doing bump-in-the-API plus mandating Apps work 
properly, and then waiting, and weeding out apps that didn't work because 
some mobile operators said "we're going to deploy this on a per-device 
type basis" after testing that these workarounds were successful.

MacOS is in-between, because applications that use the Apple APIs get 
bump-in-the-API help, but the ones that use the socket API doesn't. So 
here it's a mix of both worlds.

Windows has none of this. Linux also has none of this out of the box on 
any flavour of Linux I am aware of. This means lots of applications do not 
work.

Long tail of applications, is long.

Believing that all apps will get fixed on Windows and Linux (and MacOS) is 
for me a veeeeery long game to play. Also it's a nice idea to start 
opening tickets and trying to get them fixed, but again. Long tail is 
long.

So only practical way forward here I can see that would yield rewards in 
the next few years is for OSes to implement bump-in-the-API even for 
legacy socket API using applications, that would automatically turn on 
NAT64 traversal for legacy IPv4 applications.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 19 Nov 2017 07:39:05 +0000

Fully agree with Ole, but not in one specific point …

-> We want a situation where IPv4 only services are fronted by IPv6, and the cost born by those operating those services.

I don’t see an easy way for people with IPv4-only services to pay for the cost. If I’m an ISP and want to connect customers to Internet, even if I deploy IPv6, if I don’t provide myself a NAT64 (probably together with CLAT at the CEs), my customers will go away, because I’ve no solution to “charge” the cost of my NAT64 to the “bad and outdated” service providers that rely only in IPv4 (and IPv4-only DNSSEC).

Also, if I want customers that have IPv4-only devices at home, I still need to provide some sort of IPv4-as-a-service for that.

If we pretend that to happen, either we find a *real* way to make responsibles of the cost to the “ugly” content providers, or we will fail again as we failed assuming that dual-stack will be deployed at the right time so we can turn-off IPv4.

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Ole Troan <[email-masked]>
Responder a: <[email-masked]>
Fecha: domingo, 19 de noviembre de 2017, 1:03
Para: Brian E Carpenter <[email-masked]>
CC: 6man WG <[email-masked]>, Mark Andrews <[email-masked]>
Asunto: Re: IPv6 only host NAT64 requirements?

    Brian,

    

    
    
    Ole

---

From: Simon Hobson <[email-masked]>
Date: Sun, 19 Nov 2017 10:52:37 +0000

Mikael Abrahamsson <[email-masked]> wrote:

> Believing that all apps will get fixed on Windows and Linux (and MacOS) is for me a veeeeery long game to play. Also it's a nice idea to start opening tickets and trying to get them fixed, but again. Long tail is long.

Indeed, and I think you can probably measure that in decades rather than years !
Simple example - Windows XP "should" be dead, but it's not. There are still a lot of XP machines still in use (we have one in the house) on the basis that "it still works, why fix it ?"
My Mum still uses an old eMac running (IIRC) OS X 10.5 - on the basis that she knows how to drive it, and switching her to something newer will take "a bit of learning time" which is hard for someone her age and state of forgetfulness. I do have a newer computer for her, but it's finding time to sit down and explain all the differences - so far in preparation, she's been switched from Eudora to Apple Mail so that's one big change dealt with.

So yes, just wishing for IPv4 to go away in a few years because "everything will support IPv6" is just wishful thinking. No ISP is going to do something that's going to break a proportion of their customers' setups - just the helpdesk time (explaining that it's time for an upgrade) would cost them a fortune.

---

From: Ca By <[email-masked]>
Date: Sun, 19 Nov 2017 14:10:38 +0000

On Sun, Nov 19, 2017 at 1:45 AM Mikael Abrahamsson <[email-masked]> wrote:

> Windows has none of this.

Windows supports 464xlat

https://blogs.technet.microsoft.com/networking/2017/07/13/core-network-stack-features-in-the-creators-update-for-windows-10/

Linux also has none of this out of the box on

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 19 Nov 2017 15:45:52 +0100 (CET)

> https://blogs.technet.microsoft.com/networking/2017/07/13/core-network-stack-features-in-the-creators-update-for-windows-10/

Only on 3GPP interfaces, not on regular NICs.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 20 Nov 2017 10:17:14 +1100

> On 19 Nov 2017, at 8:45 pm, Mikael Abrahamsson <[email-masked]> wrote:
> 
> When I speak to vendors about this, I get different answers. Some are saying "nobody will deploy IPv6 only, so why should I make changes in my desktop OS to support it for legacy applications?”

Well as this stage you can say that there are ISP that are deploying IPv6-only on
the access network with DS-Lite to provide IPv4 as a service.  If you want your
host to be able to connect directly to such ISPs you need to add support to detect
that DS-Lite is in use (a IPv6 DHCP option) and bring up a IPv4 in IPv6 tunnel to
the ISPs B4 router.

Repeat this for other transition technologies that you are aware is in use.

> And I imagine any access provider will say "I can't deploy IPv6 only, because it'll break a lot of applications that people are using on desktop OSes".
> 

You stop talk ipv6-only and start talking ipv6-only access + ipv4 as a service.

It’s only a “catch 22” because people fail to look at the options available.  ISPs
are going ipv6-only access + ipv4 as a service because it is easier to manage than
dual stack access + 44CGN.   Many ISPs deliver CPE routers that support DS-Lite
so the customer still see IPv4 + IPv6.

The question to host vendors is “do you want your machines to be able to connect
directly to ISP’s that have ipv6-only access networks or not?”  Ipv6-only access
networks are a reality.

> This was fixed on Android by throwing up hands and giving up on IPv6 only, and just installing CLAT on it to make sure most legacy applications just work.
> 
> On iOS it was fixed by doing bump-in-the-API plus mandating Apps work properly, and then waiting, and weeding out apps that didn't work because some mobile operators said "we're going to deploy this on a per-device type basis" after testing that these workarounds were successful.
> 
> MacOS is in-between, because applications that use the Apple APIs get bump-in-the-API help, but the ones that use the socket API doesn't. So here it's a mix of both worlds.
> 
> Windows has none of this. Linux also has none of this out of the box on any flavour of Linux I am aware of. This means lots of applications do not work.
> 
> So only practical way forward here I can see that would yield rewards in the next few years is for OSes to implement bump-in-the-API even for legacy socket API using applications, that would automatically turn on NAT64 traversal for legacy IPv4 applications.
> 
> --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 20 Nov 2017 07:35:02 +0100 (CET)

> that DS-Lite is in use (a IPv6 DHCP option) and bring up a IPv4 in IPv6 tunnel to

Most ds-lite networks are DOCSIS networks, and no host can connect 
directly to that. They'll end up behind a router, which will give the host 
a dual stack service. Sure, you can bridge the modem but the expectation 
is still that you'll connect a ds.lite capable router to that.

> You stop talk ipv6-only and start talking ipv6-only access + ipv4 as a service.

Same thing. Not helping.

> It’s only a “catch 22” because people fail to look at the options 
> available.  ISPs are going ipv6-only access + ipv4 as a service because 
> it is easier to manage than dual stack access + 44CGN.  Many ISPs 
> deliver CPE routers that support DS-Lite so the customer still see IPv4 
> + IPv6.

No, ISPs are not doing that, because hosts do not work properly in this 
scenario. iOS and Android does, but nothing else. So the "else" software 
vendors can just sit back, do nothing and play chicken race.

> The question to host vendors is “do you want your machines to be able to 
> connect directly to ISP’s that have ipv6-only access networks or not?” 
> Ipv6-only access networks are a reality.

I doubt vendors get any feature requests to support this scenario. When 
it doesn't work, people will blame the ISP. This means ISPs won't deply 
this.

---

From: <[email-masked]>
Date: Mon, 20 Nov 2017 07:41:48 +0000

Hi Ole,

Please see inline. 

Cheers,
Med

> De : Ole Troan [mailto:[email-masked]]
> Envoyé : vendredi 17 novembre 2017 10:20
> Cc : Jen Linkova; 6man WG; Mark Andrews
> For the IETF NAT64 IMHO

[Med] As you are mentioning "IETF" explicitly, NAT64 may not be the appropriate "IPv4 service continuity" solution here. 

>    64:ff9b::127.0.0.1 (or perhaps just 64:ff9b::)

[Med] Fair. That is another "add my favorite solution" to the list. 

> Btw, for multiple NSPs, couldn't you partly solve that by injecting more

[Med] It is not only about forwarding/routing, but also how a host can pick the appropriate prefix64 for address synthesis. Things may be obvious if you can consider the example of RFC7050:

                      NAT64 "A" ----- IPv4-only servers in a data center
                     /
   IPv6-only node---<
                     \
                      NAT64 "B" ----- IPv4 Internet 

> > [Med] I also disagree with many of the points in RFC7051, but that is
> the document which reflects the IETF consensus on learning prefix64s.
> >
> > We had many opportunities in the past to ignore the recommendations in
> RFC7051, but we didn't. For example, RFC8115 says the following:
> >
> > ==
> > [Med] It is evident that RA-based approach may be a good candidate for
> some deployments. Others may argue that another solution is appropriate
> for their deployment, and so on.
> >
> >>
> >>>> gives up one of the major advantages of NAT64/DNS64, which is that
> it's
> >> a
> >>>>>> requiring more and more highly invasive node changes to support.
> It
> >>>> was from the very beginning
> >>>>>> being written but the working group decide that CD indicated
> whether
> >>>> the client was validating or

---

From: Ole Troan <[email-masked]>
Date: Mon, 20 Nov 2017 09:33:30 +0100

Hi Med,

> [Med] As you are mentioning "IETF" explicitly, NAT64 may not be the appropriate "IPv4 service continuity" solution here.

Why not?
Interesting to hear your views here, especially since it "almost" worked at IETF100.

>                      NAT64 "B" ----- IPv4 Internet

Firstly this seems like it is over engineered. Has anyone actually deployed NAT64 this way?
(Given that this is quite rare even in IPv6 only or IPv4 only scenarios. Look at implementation status of RIO for example).

Secondly, RFC7050 says:

   The heuristic discovery method described herein does not support
   learning of the possible rules used by a DNS64 server for mapping
   specific IPv4 address ranges to separate Pref64::/n prefixes.
   Therefore, nodes will use the same discovered Pref64::/n to
   synthesize IPv6 addresses from any IPv4 address.  This can cause
   issues for routing and connectivity establishment procedures.  The
   operator of the NAT64 and the DNS64 ought to take this into account
   in the network design.

Which to me reads, this just doesn't work.

If we think NAT64 is a fundamental piece of technology to make progress on the transition, then I think we should focus on making it as simple and deployable as possible.

Cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Mon, 20 Nov 2017 09:40:50 +0100

Mark,

> directly to ISP’s that have ipv6-only access networks or not?”  Ipv6-only access

From the perspective of the host and the application, "IPv4 as a service" is hardly progress.
(Progress being defined as something moving us towards an IPv6 only network).

IPv4aaS offers dual stack to the hosts. Sure, it is typically carried over IPv6, and it allows the access network to use IPv6 transport. But from the perspective of delivering the service, it could as well have been ATM.

The other coin of IPv4aaS is that it is a mechanism that allows IPv4 to scale indefinitely.

The tragicomedy of where we are at the moment is that an ISP would offer better service to the end-user network by delivering IPv4 only service over it's IPv4aaS infrastructure... we need to find a way to move off dual-stack.

Ole

---

From: <[email-masked]>
Date: Mon, 20 Nov 2017 09:52:22 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : lundi 20 novembre 2017 09:34
> > [Med] As you are mentioning "IETF" explicitly, NAT64 may not be the
> appropriate "IPv4 service continuity" solution here.
> 
> Why not?

[Med] Because dual-stack can do the job without any extra effort.

> Interesting to hear your views here, especially since it "almost" worked

[Med] I don't have any doubt that NAT64 will work module some issues and fixes (more can be found in https://tools.ietf.org/html/rfc6889#section-3 (Analysis of Stateful 64 Translation)). There are deployments cases where these fixes are wroth to be enforced, while it is not justified in others. I'm for NAT64 as an "IPv4 service continuity" for mobile networks where there is a pressure on private IPv4 addresses, but I'm for DS-Lite and MAP-E for fixed networks given there is no implications on the host itself; the "complexity" will be hidden by a CPE. 

It is a case by case exercise.

> >> - If the host couldn't learn the NAT64 prefix any other way, I suppose
> it
> >> could throw an ICMP echo towards
> >> Btw, for multiple NSPs, couldn't you partly solve that by injecting
> more
> >> specifics into routing?
> >
> > [Med] It is not only about forwarding/routing, but also how a host can
> pick the appropriate prefix64 for address synthesis. Things may be obvious
> if you can consider the example of RFC7050:
> >
> >

[Med] This is a scenario that can be considered by some mobile operators at the Gi interface. Multiple prefixes are discussed in Section 4.2. of RFC7269 (NAT64 Deployment Options and Experience) that was produced by v6ops.

> (Given that this is quite rare even in IPv6 only or IPv4 only scenarios.
> Look at implementation status of RIO for example).
> 
> Secondly, RFC7050 says:
> 

[Med] Correct. This is one of the limitations of the heuristic approach.  

> 
> If we think NAT64 is a fundamental piece of technology to make progress on
> the transition, then I think we should focus on making it as simple and
> deployable as possible.

[Med] NAT64 spec does not make any assumption about the deployment case. Its limitations are well-known and documented since years. 

IMHO, the required pieces for "simple" deployment scenarios are out there:
- prefix discovery using the heuristic
- local address synthesis to solve issues related to address literals/referrals. 

Advanced features have been also specified, e.g., 
- if you want to allow for incoming connections: e.g., access a video server
- if you want to avoid overloading NAT64 with all sorts of ALGs
- if you want to avoid draining the battery of your mobile because of the keepalive messages
- ...

---

From: Ole Troan <[email-masked]>
Date: Mon, 20 Nov 2017 11:37:56 +0100

Med,

> [Med] Because dual-stack can do the job without any extra effort.

That's not a valid answer, when the question to be explored is "Is it possible to run IPv6 only hosts?".

The arguments against dual stack:
 - expensive to operate
 - little progress towards the end goal of IPv6 only

I think you can make a fair case that the end-user experience today is best with IPv4 only.

> It is a case by case exercise.

Again, trying to move us forward with IPv6 only hosts.

> [Med] This is a scenario that can be considered by some mobile operators at the Gi interface. Multiple prefixes are discussed in Section 4.2. of RFC7269 (NAT64 Deployment Options and Experience) th…

You can achieve load-balancing without having to push that requirement all the way down to the host.

> - if you want to avoid draining the battery of your mobile because of the keepalive messages

Yep, but I think the cat is largely out of the bag here, and an application must work in the "smallest common denominator" network.

Cheers,
Ole

---

From: Mark Andrews <[email-masked]>
Date: Mon, 20 Nov 2017 22:12:12 +1100

> On 20 Nov 2017, at 7:40 pm, Ole Troan <[email-masked]> wrote:
> 
> Mark,
> 

IPv4aaS delivers IPv6 connectivity to the customer net.  That is better than IPv4 only.  It moves the global percentage of IPv6 traffic upwards.  It allows customers to offer services on well known ports.  We need to reach 90 something percent IPv6 traffic before most people will be willing to turn off IPv4.

I’d prefer mechanisms that can be out sourced so ISPs can off the deliver of IPv4 as a service to someone else in the future.  The costs then go back onto only those that need to reach legacy only services.

> The other coin of IPv4aaS is that it is a mechanism that allows IPv4 to scale indefinitely.

There are limits to how many customers can share a IP address especially if you are allowing incoming connections by mapping ports to customers.   Even stateless mapping, eyeball only, imposes costs.

> The tragicomedy of where we are at the moment is that an ISP would offer better service to the end-user network by delivering IPv4 only service over it's IPv4aaS infrastructure... we need to find a…

Moving off dual stack will come.  It just hard to force it.  Encouraging every small step in the right direction is important.

I’m sure there are a couple of Summer of Code projects in going through the existing applications that make network connections and 1) adding IPv6 support if it doesn’t exist and 2) adding happy eyeball style connection creation where the application is {S}TCP based.  Contribute those changes back to the projects.

---

From: Ole Troan <[email-masked]>
Date: Mon, 20 Nov 2017 12:32:27 +0100

Mark,

> IPv4aaS delivers IPv6 connectivity to the customer net.  That is better than IPv4 only.  It moves the global percentage of IPv6 traffic upwards.  It allows customers to offer services on well known…

But for _me_ on my local network, with my applications... I haven't found anything better with it...
examples?

> There are limits to how many customers can share a IP address especially if you are allowing incoming connections by mapping ports to customers.   Even stateless mapping, eyeball only, imposes cost…

Not really. A+P gives you 48 bit addressing. ;-)
And especially not with upcoming new transport layers.
With traditional NAT, you burn one outside NAT port per multiple connections to same external destination:port.
We should ask CAIDA for an analysis.
Continuing to scale IPv4 is possible. It's not going to be free... far from it, but that seems to be where we're backwards walking ourselves into.

> Moving off dual stack will come.  It just hard to force it.  Encouraging every small step in the right direction is important.

But I think we should encourage it, we should make it as edible as possible, and we should try to push the burden of interoperability over to the laggards.

> I’m sure there are a couple of Summer of Code projects in going through the existing applications that make network connections and 1) adding IPv6 support if it doesn’t exist and 2) adding happy ey…

As I said we didn't find many applications during the hackathon.
The main culprits in my home is bath scale, light bulbs, weather stations.
The other culprits are the plethora of open source projects around VM and container networking, those are largely IPv4 NAT based.

Cheers,
Ole

---

From: <[email-masked]>
Date: Mon, 20 Nov 2017 12:21:27 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : lundi 20 novembre 2017 11:38

[Med] You should admit that there are questions that don't make sense if not contextualized.  

>  - little progress towards the end goal of IPv6 only

[Med] These are generic statements, Ole. We are talking about the IETF case. 
* The IETF has no control on the hosts that connect to the IETF network,
* IETF attendees who are using corporate devices, have no control on these hosts

So, how forcing devices to use "IPv6+nat64" will help here? 

> I think you can make a fair case that the end-user experience today is

[Med] It depends for "which user", Ole. Consider the example of a bittorrent user who may prefer IPv6 vs. IPv4.

> 
> >> Interesting to hear your views here, especially since it "almost"
> worked
> >> at IETF100.
> >
> > [Med] I don't have any doubt that NAT64 will work module some issues and
> fixes (more can be found in https://tools.ietf.org/html/rfc6889#section-3
> (Analysis of Stateful 64 Translation)). There are deployments cases where
> these fixes are wroth to be enforced, while it is not justified in others.
> I'm for NAT64 as an "IPv4 service continuity" for mobile networks where
> there is a pressure on private IPv4 addresses, but I'm for DS-Lite and
> MAP-E for fixed networks given there is no implications on the host
> itself; the "complexity" will be hidden by a CPE.
> >
> > [Med] This is a scenario that can be considered by some mobile operators
> at the Gi interface. Multiple prefixes are discussed in Section 4.2. of
> RFC7269 (NAT64 Deployment Options and Experience) that was produced by
> v6ops.
> 

[Med] I know. There is no reco to achieve NAT64 load-balancing. It is legitimate to hear from both of them. 

> > [Med] NAT64 spec does not make any assumption about the deployment case.
> Its limitations are well-known and documented since years.
> >
> Yep, but I think the cat is largely out of the bag here, and an
> application must work in the "smallest common denominator" network.

[Med] More concretely?

---

From: Ole Troan <[email-masked]>
Date: Mon, 20 Nov 2017 14:36:53 +0100

Med,

> [Med] You should admit that there are questions that don't make sense if not contextualized.

Freely admitted. Although I thought that was made clear both earlier in thread and by subject. ;)

> So, how forcing devices to use "IPv6+nat64" will help here?

Eat own dogfood. Many IETF people are developers or work for companies having applications not working.
As I said there were a minimum of applications that didn't work. Corporate VPNs largely did. Jen has the final numbers.

[...]

>> application must work in the "smallest common denominator" network.

- ALGs do more harm than gain. Applications have been forced to deal with NAT traversal. As in ICE/STUN/TURN.
  Applications must work with any NAT also those without ALGs. ALGs are dead.
- For the applications that need the keepalive wouldn't they send traffic anyway, so that it wouldn't be an additional battery drain.
  Example of application that doesn't?
- Incoming connections? Didn't think we did that on the Internet anymore? :-(
  That's static configuration in one case, and for the other symmetric hole punching (as in the ICE/STUN case).

Would PCP have helped, yes, possibly, but given that applications must work without it anyway...

Cheers,
Ole

---

From: Michael Richardson <[email-masked]>
Date: Mon, 20 Nov 2017 09:04:42 -0500

> Firstly this seems like it is over engineered. Has anyone actually

Yes, it's a really good way to deal with overlapping RFC1918 ranges (used for
managing devices) in different data centers. (The boot server is always at
192.168.1.2, the serial console is always at 192.168.1.3, etc.)

I've done this as far back as 2008 (with "NAT64" being implemented by a TCP
proxy terminating the entire IPv6/32)

I didn't have to pick the right source address, but I can see how this might
be an issue.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 20 Nov 2017 15:09:38 +0100

> Eat own dogfood. Many IETF people are developers or work for companies having applications not working.

Agreed.

> As I said there were a minimum of applications that didn't work. Corporate VPNs largely did. Jen has the final numbers.

My VPN did not work and I wont be able to make my employer change the VPN.

Alex

---

From: Ole Troan <[email-masked]>
Date: Mon, 20 Nov 2017 15:27:43 +0100

Michael,

At the risk of making the 6man list into behave...

> I didn't have to pick the right source address, but I can see how this might

Right, but how would a host know which NAT64 prefix to combine 192.168.1.2 with?

Cheers,
Ole

---

From: <[email-masked]>
Date: Mon, 20 Nov 2017 14:47:12 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : lundi 20 novembre 2017 14:37
> As I said there were a minimum of applications that didn't work. Corporate
> VPNs largely did. Jen has the final numbers. 
> 
> [...]
> 
> - ALGs do more harm than gain.

[Med] Fully agree. 

 Applications have been forced to deal with
> NAT traversal. As in ICE/STUN/TURN.

[Med] I used to know that ICE failure rate for webrtc, for example, is high. I don't know if that situation changed since then.  

> - For the applications that need the keepalive wouldn't they send traffic
> anyway, so that it wouldn't be an additional battery drain.

[Med] You can consider the example of a SIP application that send keepalives even if there no ongoing media session. If that application knows the assigned lifetime, it will adjust according. 

The problem is about the default value of the keepalive message. For example, ipsec uses 20s. Other protocols are setting this value to 15s or 30s. Below an excerpt of the impact on the battery as a function of the default value:

                According to [Power], the consumption of a cellular
                device with a keep-alive interval equal to 20 seconds
                (which is the default value in [RFC3948], for example)
                is 29 mA (2G) / 34 mA (3G).  This consumption is reduced
                to 16 mA (2G) / 24 mA (3G) when the interval is
                increased to 40 seconds, to 9.1 mA (2G) / 16 mA (3G) if
                the interval is equal to 150 seconds, and to 7.3 mA (2G)
                / 14 mA (3G) if the interval is equal to 180 seconds.
                When no keep-alive is issued, the consumption would be
                5.2 mA (2G) / 6.1 mA (3G).  The impact of keepalive
                messages would be more severe if multiple applications
                are issuing those messages (e.g., SIP, IPsec, etc.).

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Nov 2017 08:37:28 +1300

On 21/11/2017 02:36, Ole Troan wrote:
...>> [Med] These are generic statements, Ole. We are talking about the IETF case.
> As I said there were a minimum of applications that didn't work. Corporate VPNs largely did. Jen has the final numbers.

However, as long as even one application, such as one VPN, or one
literal IPv4 address, fails, that represents millions of failure cases
if we consider the whole world (e.g. imagine every hotel network in
the world running IPv6+NAT64 only). That simply isn't viable. Dual
stack in every hotel room in the world is viable, from the hotel guests'
point of view. Operators might not like it, but users wouldn't care.

    Brian

---

From: Ole Troan <[email-masked]>
Date: Mon, 20 Nov 2017 20:52:35 +0100

> point of view. Operators might not like it, but users wouldn't care.

Nor would they if the hotel room was IPv4 only...
Would they?

Ole

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 20 Nov 2017 21:10:32 +0100

It is clear to me that hotel rooms need to provide IPv6 + IPv4-as-a-service (for example using a CE or AP with CLAT).

The hotel network or its access can be IPv6-only and then the ISP provide the NAT64.

I’m sure someone will argue that this means perpetuating IPv4: Is not the case.

The case is being realistic about what an ISP or an hotel or any other organizations NEEDs to provide to their customers if they want to keep them.

If the hotels provide IPv6 + IPv4-as-a-service, the customer is happy and more and more traffic is moving from IPv4 to IPv6 in a natural way.

If some app developers don’t see it, or if some content providers or enterprises where the VPN is being connected, there will be a point where the IPv4 traffic is meaningless and they have the risk that at that point the IPv4-as-a-service is not offered anymore, not because the cost of the CLAT, but because the cost of the NAT64.

The only way we can motivate all them to move to IPv6 is to make sure that when, for example 75% of the Internet traffic is IPv6, we clearly announce that IPv4 is historical, has not maintenance, and will be dropped and unsupported and will not be able to be reachable. It is the ISPs work to decide if they want to keep providing NAT64 or not, and to tell their customers. At some point, more and more ISPs will drop that service. Wherever that point is at the 75% of IPv6 traffic or 95% or something in the middle is to be decided by each ISP, also maybe depending on their competitors, etc.

I recall a few years ago when a phone company in Spain still had a few customers with old “pulse disk phones”. They took the decision to cancel the contract to those customers if they don’t want to get the phone replaces with DTMF phones.

Same today is happening with customers with ADSL where there is GPON coverage. You accept to be replaced to GPON, or they cancel the contract, because it is more expensive to keep a few “old fashioned” customers that the profit they generate.

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Brian E Carpenter <[email-masked]>
Organización: University of Auckland
Responder a: <[email-masked]>
Fecha: lunes, 20 de noviembre de 2017, 20:37
Para: Ole Troan <[email-masked]>, Mohamed Boucadair <[email-masked]>
CC: 6man WG <[email-masked]>, Mark Andrews <[email-masked]>
Asunto: Re: IPv6 only host NAT64 requirements?

    
        Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 20 Nov 2017 20:12:16 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter

> literal IPv4 address, fails, that represents millions of failure
> cases if we consider the whole world (e.g. imagine every hotel
> network in the world running IPv6+NAT64 only).

Very instructive thread for me, I must say. I'm getting this sense of urgency, to be rid of IPv4, but it comes from the IETF 6man wg and some ISPs. Ultimately, it's not up to 6man to decide. It's up to device vendors, and up to the deployed base of devices. The IETF can only suggest, and ISP networks have to meet the real world needs.

> Dual stack in every hotel room in the world is viable, from the
> hotel guests' point of view.

This seems the most practical answer, whether it's a client server model, such as in a hotel room, or a peer to peer network. In a mostly peer to peer network, the normal case would be for IPv6 hosts to be introduced gradually. I'm not sure how anything other than dual stack can work, in this case. If the goal is to have continuous robust operation of the network, during an indefinitely long transitional phase, because no one up the chain could care less about the nitty gritty, they just want everything to keep working flawlessly, then what motivation would there be for anything other than dual stack? The only practical solution is to introduce IPv6 hosts only if they are dual stack. And then carefully, on a case by case basis, individual subsystems that do not need to interoperate with IPv4 subsystems can shut off IPv4.

I realize that such transition drag on for years. But again, in the greater scheme of things, this matters very little to those who must make sure the systems work at all times.

Bert

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 20 Nov 2017 21:12:50 +0100

And by the way …

At some point the NAT64 service, instead of being provided by the ISP it will make sense to be provided by third party companies, even if there is some extra delay to reach a remote NAT64, etc., and even if there is an extra cost for that customer that still requires it.

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de JORDI PALET MARTINEZ <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 20 de noviembre de 2017, 21:11
Para: 6man WG <[email-masked]>
Asunto: Re: IPv6 only host NAT64 requirements?

    

    

    
    
    Regards,
    Jordi

    -----Mensaje original-----
    De: ipv6 <[email-masked]> en nombre de Brian E Carpenter <[email-masked]>
    Organización: University of Auckland
    Responder a: <[email-masked]>
    Fecha: lunes, 20 de noviembre de 2017, 20:37
    Para: Ole Troan <[email-masked]>, Mohamed Boucadair <[email-masked]>
    CC: 6man WG <[email-masked]>, Mark Andrews <[email-masked]>
    Asunto: Re: IPv6 only host NAT64 requirements?

        
            Brian

---

From: Jen Linkova <[email-masked]>
Date: Tue, 21 Nov 2017 07:33:50 +1100

On Tue, Nov 21, 2017 at 7:12 AM, Manfredi, Albert E
<[email-masked]> wrote:
> Very instructive thread for me, I must say. I'm getting this sense of urgency, to be rid of IPv4, but it comes from the IETF 6man wg and some ISPs.
>Ultimately, it's not up to 6man to decide.

I do not see this thread as 6man deciding that everyone is to get rid
of Ipv4 right now. I see it as 'there are networks deploying IPv6-only
hosts and 6man is discussing how to help hosts to operate in such
environment'.

>It's up to device vendors,  and up to the deployed base of devices.
>The IETF can only suggest, and ISP networks have to meet the real world needs.

People from the real world is coming to IETF saying 'we are deploying
Ipv6-only hosts' [1] [2]

References:
[1[ https://datatracker.ietf.org/meeting/100/materials/slides-100-v6ops-sessa-ipv6-only-deployment-at-cisco/
[2] https://datatracker.ietf.org/meeting/99/materials/agenda-99-v6ops/

---

From: Jen Linkova <[email-masked]>
Date: Tue, 21 Nov 2017 07:53:14 +1100

>> So, how forcing devices to use "IPv6+nat64" will help here?

I'm still working on the experiment results write-up but off top of my
head I can tell you that:
1) people told me they are coming back to their IT departments asking
them to fix their VPNs. As there are other places out there providing
Ipv6-only as a 'primary/default' wifi (AFAIR FOSDEM is doing this, for
example, not mentioning some companies deploying v6-only networks) I
think it's quite useful for those people to be prepared.
2) bug reports for the broken applications were filled
3) we finally have some numbers on 'what % of people can not get their
work done if their devices do not have v4 addresses' - before it was
just
'some saying that it would never work while others saying it works just fine'.
4) we observed that the situation has improved even since IETF99 so we
are moving in right direction.
5) as a result of the experiment some changes have been applied to the
IETF network to improve it and bugs opened with vendors.
6) we are having this discussion in 6man about host requirements.

on Friday afternoon I discovered that I had turned off Ipv4 on my
laptop on Tue morning and left it like that...Noticed it only because
got connected
to Ipv4-only network ;)))

> As I said there were a minimum of applications that didn't work. Corporate VPNs largely did. Jen has the final numbers.

Stay tuned, I'm getting the numbers together, will get it done this week.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 20 Nov 2017 20:59:46 +0000

-----Original Message-----
From: Jen Linkova [mailto:[email-masked]] 

References:

Okay. So, people can follow whatever approach they prefer, but my first reaction was that switching over to IPv6 *by location* seems an odd way to go about it. If it were up to me, I'd say not to use that model. It's more a matter of end to end functions used, by hosts in a given subnet. If a given subnet can demonstrate that all of its hosts' needs can be met, end to end, with IPv6 only, then great. Shut off IPv4 in that one subnet. But "end to end" sessions are frequently not confined to one location, and it also seems unlikely that all hosts in all subnets, in a given location, have the same needs.

The hotel model that Brian offered seems to reflect what should be the most generic reality. Diverse devices, diverse needs, location isn't the primary factor to be considered. I realize that there's some sort of management appeal, to make this a "by location" issue.

Bert

---

From: Lee Howard <[email-masked]>
Date: Mon, 20 Nov 2017 16:05:19 +0800

On 11/21/17, 4:12 AM, "ipv6 on behalf of Manfredi, Albert E"
<[email-masked] on behalf of [email-masked]> wrote:

>Very instructive thread for me, I must say. I'm getting this sense of
>urgency, to be rid of IPv4, but it comes from the IETF 6man wg and some
>ISPs. Ultimately, it's not up to 6man to decide. It's up to device
>vendors, and up to the deployed base of devices. The IETF can only
>suggest, and ISP networks have to meet the real world needs.

It’s a multi-legged stool, where network operators, device vendors, and
content all have a role, and will make their own operational decisions.
Operators may decide not to support IPv4-only devices or applications, or
to charge more for them, or to provide translators. Device makers may
decide to support dual-stack, or CLAT, or IPv6-only, or IPv4-only. Etc.

>This seems the most practical answer, whether it's a client server model,
>such as in a hotel room, or a peer to peer network. In a mostly peer to
>peer network, the normal case would be for IPv6 hosts to be introduced
>gradually. I'm not sure how anything other than dual stack can work, in
>this case. If the goal is to have continuous robust operation of the
>network, during an indefinitely long transitional phase, because no one
>up the chain could care less about the nitty gritty, they just want
>everything to keep working flawlessly, then what motivation would there
>be for anything other than dual stack?

IPv4 addresses selling for US$15 each and rising? At what price do
operators stop doing native dual stack?

> The only practical solution is to introduce IPv6 hosts only if they are
>dual stack. And then carefully, on a case by case basis, individual
>subsystems that do not need to interoperate with IPv4 subsystems can shut
>off IPv4.

It’s too late for dual-stack to be the transition plan.

>
>I realize that such transition drag on for years. But again, in the
>greater scheme of things, this matters very little to those who must make
>sure the systems work at all times.

Yes, years.
https://pbs.twimg.com/media/C_vRuRUXYAAwxN5.jpg:large
Five years until 90% of hosts have IPv6. It’s going to be a bumpy few
years, especially for those who insist IPv6 is somebody else’s problem.

Lee

---

From: Lee Howard <[email-masked]>
Date: Mon, 20 Nov 2017 16:18:45 +0800

On 11/21/17, 4:59 AM, "ipv6 on behalf of Manfredi, Albert E"
<[email-masked] on behalf of [email-masked]> wrote:

>[1[ 
>https://datatracker.ietf.org/meeting/100/materials/slides-100-v6ops-sessa-
>ipv6-only-deployment-at-cisco/
>Okay. So, people can follow whatever approach they prefer, but my first
>reaction was that switching over to IPv6 *by location* seems an odd way
>to go about it. If it were up to me, I'd say not to use that model. It's
>more a matter of end to end functions used, by hosts in a given subnet.
>If a given subnet can demonstrate that all of its hosts' needs can be
>met, end to end, with IPv6 only, then great. Shut off IPv4 in that one
>subnet. But "end to end" sessions are frequently not confined to one
>location, and it also seems unlikely that all hosts in all subnets, in a
>given location, have the same needs.

Not sure what your goal is here in complaining about someone else’s
deployment model.

A building on a campus probably is a single subnet. Not sure how you’d
find out what doesn’t work over IPv6 (plus NAT64) without trying it.

>
>The hotel model that Brian offered seems to reflect what should be the
>most generic reality. Diverse devices, diverse needs, location isn't the
>primary factor to be considered. I realize that there's some sort of
>management appeal, to make this a "by location" issue.

Hospitality networks have specific engineering requirements which may not
be generalizable. For one, they have different users and devices daily:
unlike an enterprise network, devices that tech support fixes don’t stay
fixed (new devices come in). A support call to an ISP subscriber might
cost the same or less than a hotel support call, but if the call is
repeated every time there’s a new user, the hotel has a very different
problem. Plus, of course, hotels are pretty much all Wi-Fi, which may not
be true of enterprise or campus or data center networks.

Lee

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Nov 2017 11:38:59 +1300

> The hotel network or its access can be IPv6-only and then the ISP provide the NAT64.

What users need is that the WiFi (or, rarely, the RJ45 connector) supports
native IPv4 and native IPv6. If  the SP wants IPv6-only on the hotel's
access link, then the hotel's CE must use one of the known solutions.
I don't care if it's CLAT or dslite or homebrew. It must not place unusual
requirements on the user's device, since by definition in such a scenario
the user device and its applications are random and only a lowest common
denominator can be assumed.

> I’m sure someone will argue that this means perpetuating IPv4: Is not the case.

The religious aspect is not important; the market doesn't care about
religion. IPv4 will die when it's ready to die, and not before.

> If the hotels provide IPv6 + IPv4-as-a-service, the customer is happy 

And I believe that is the *only* way to make all customers happy
while deploying IPv6. Also, it can only be motivated if accessing
Facebook, Google etc. is faster or cheaper using IPv6, providing
an incentive for change.

> and more and more traffic is moving from IPv4 to IPv6 in a natural way.
> 

Whatever the reason, ISPs won't do this until it affects a
negligible number of users, given the cost of help desk
calls compared to everything else.

> The only way we can motivate all them to move to IPv6 is to make sure that when, for example 75% of the Internet traffic is IPv6, we clearly announce that IPv4 is historical, has not maintenance, and will be dropped and unsupported and will not be able to be reachable. 

I don't know who you mean by "we". Certainly the IETF has no
power to make such statements.

Regards,
   Brian

> It is the ISPs work to decide if they want to keep providing NAT64 or not, and to tell their customers. At some point, more and more ISPs will drop that service. Wherever that point is at the 75% of IPv6 traffic or 95% or something in the middle is to be decided by each ISP, also maybe depending on their competitors, etc.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Nov 2017 11:44:00 +1300

On 20/11/2017 21:05, Lee Howard wrote:
...
 
> It’s too late for dual-stack to be the transition plan.

In my mind it never was a transition plan. It was, and remains,
a co-existence plan, which will go away when co-existence
is no longer needed.

One thing that we demonstrated very convincingly last week
is that there are enough legacy devices and applications in
existing user hosts that the co-existence plan is still needed.
(And, BTW, we demonstated it for user hosts belonging to
relatively sophisticated users.)

    Brian

---

From: Ole Troan <[email-masked]>
Date: Mon, 20 Nov 2017 23:51:12 +0100

Brian,

> relatively sophisticated users.)

Huh?
Data please.

Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Nov 2017 12:30:57 +1300

>> relatively sophisticated users.)

Well, I assume that Jen et al will produce a summary report, but
the number of tickets at https://tickets.meeting.ietf.org/wiki/nat64
tells me that ietf-nat64 did not provide a smooth co-existence
experience for everybody. Imagine that each of those tickets equates
to one support call per week, multiplied by the number of hotels
in the world.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Nov 2017 12:44:52 +1300

Jen,
> hosts and 6man is discussing how to help hosts to operate in such

Fair enough. But now, and for many years, IPv6-only hosts** will
be unusual (except on some cellular networks); IPv4-only hosts are 
common, and dual stack hosts are common.

** In my book, a host that contains even one IPv4-only application
cannot be considered as an "IPv6-only" host.
 
> People from the real world is coming to IETF saying 'we are deploying

Sure. And I think the tests last week showed two things:
1. NAT64/DNS64 is viable for IPv6-only hosts (setting aside DNSSEC).
2. IPv6-only hosts are far from universal, even among IETF
participants.

And BTW thanks for the effort behind ietf-nat64. I think it
was a very valuable effort.

Regards,
    Brian

---

From: Ole Troan <[email-masked]>
Date: Tue, 21 Nov 2017 00:53:26 +0100

Brian,

> to one support call per week, multiplied by the number of hotels

The purpose of the experiment was to get some real data.
Before jumping to conclusions let's get the report. No-one thought this would work without a single flaw.
And this experiment is not about providing IPv6 only service to hotels, it is about providing IPv6 only + NAT64 to the IETF network.

32 tickets. Where people were encouraged to report anything. You cannot just assume those are real issues without looking at them.
E.g. you can discount 1151, 1175, 1185, 1160, 1174, 1172, 1159 straight away.
Some tickets may contain multiple issues and so on.

Looks like we're left with a handful of applications and some OS issues. We're not talking rocket science to get those fixed.

Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Nov 2017 14:01:47 +1300

> Looks like we're left with a handful of applications and some OS issues. We're not talking rocket science to get those fixed.

Sure, and we should try. But we can't fix legacy hosts in the hands of the general public.

   Brian

---

From: Mark Andrews <[email-masked]>
Date: Tue, 21 Nov 2017 12:15:29 +1100

> On 21 Nov 2017, at 12:01 pm, Brian E Carpenter <[email-masked]> wrote:
> 

But we can send feed back to the vendors of the products they are using that the product they are shipping does not work in this environment for this reason.  More and more of their clients will be behind some sort of IPv6 as a service and there products should work in that environment.  Eventually the fixed will get deployed.

I also think it is a myth that we tell ourselves that hosts won’t get updated.  They get updated all the time provided the vendor of the product puts out a fix.  Its getting the vendor to publish the fix that is the hard part.

Mark

---

From: Masanobu Kawashima <[email-masked]>
Date: Tue, 21 Nov 2017 04:11:01 +0000

Hi Jordi, 

> At some point the NAT64 service, instead of being provided by the ISP it will make sense to be provided by third party
> companies, even if there is some extra delay to reach a remote NAT64, etc., and even if there is an extra cost for that
> customer that still requires it. 

In Japan, JPIX(Japan Internet Exchange) is providing 464XLAT trial service 
to ISPs. 
https://www.jpix.ad.jp/en/technical_exchange.php 

PLAT(NAT64 service) is providing from JPIX, then ISPs are using CLAT CPE. 
We might need this kind of service near future. 
Just FYI. :-) 

Regards, 
Masanobu 

==================================== 
 NEC Platforms, Ltd.                 
 Access-Device Division              
 KAWASHIMA Masanobu                  
 [email-masked]            
 https://www.necplatforms.co.jp/en/  
==================================== 

> From: ipv6 [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
> Sent: Tuesday, November 21, 2017 5:13 AM
> To: 6man WG <[email-masked]>
> Subject: Re: IPv6 only host NAT64 requirements?
> 
> And by the way …
> 
> At some point the NAT64 service, instead of being provided by the ISP it will make sense to be provided by third party
> companies, even if there is some extra delay to reach a remote NAT64, etc., and even if there is an extra cost for that
> customer that still requires it.
> 
> Regards,
> Jordi
> 
> 
> De: ipv6 <[email-masked]> en nombre de JORDI PALET MARTINEZ <[email-masked]> Responder a:
> <[email-masked]>
>     If some app developers don’t see it, or if some content providers or enterprises where the VPN is being connected,
> there will be a point where the IPv4 traffic is meaningless and they have the risk that at that point the IPv4-as-a-service
> is not offered anymore, not because the cost of the CLAT, but because the cost of the NAT64.
> 
>     The only way we can motivate all them to move to IPv6 is to make sure that when, for example 75% of the Internet traffic
> is IPv6, we clearly announce that IPv4 is historical, has not maintenance, and will be dropped and unsupported and will
> not be able to be reachable. It is the ISPs work to decide if they want to keep providing NAT64 or not, and to tell their
> customers. At some point, more and more ISPs will drop that service. Wherever that point is at the 75% of IPv6 traffic
> or 95% or something in the middle is to be decided by each ISP, also maybe depending on their competitors, etc.
> 
>     I recall a few years ago when a phone company in Spain still had a few customers with old “pulse disk phones”. They
> took the decision to cancel the contract to those customers if they don’t want to get the phone replaces with DTMF phones.
> 
>     Same today is happening with customers with ADSL where there is GPON coverage. You accept to be replaced to GPON,
> or they cancel the contract, because it is more expensive to keep a few “old fashioned” customers that the profit they
> generate.
> 
>     Regards,
>     Jordi
> 
> 
>     This electronic message contains information which may be privileged or confidential. The information is intended
> to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying,
> distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited
> and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying,
> distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited,
> will be considered a criminal offense, so you must reply to the original sender to inform about this communication and
> delete it.
> 
> 
> 
>     This electronic message contains information which may be privileged or confidential. The information is intended
> to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying,
> distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited
> and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying,
> distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited,
> will be considered a criminal offense, so you must reply to the original sender to inform about this communication and
> delete it.
> 
> 
> 
> 
> 
> 
> This electronic message contains information which may be privileged or confidential. The information is intended to be
> for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying,
> distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited
> and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying,
> distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited,
> will be considered a criminal offense, so you must reply to the original sender to inform about this communication and
> delete it.
> 
> 
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 21 Nov 2017 07:07:20 +0100 (CET)

> It’s too late for dual-stack to be the transition plan.

Well, I wouldn't say that. Let's augment instead:

1. IPv4
2. Dual stack
3. IPv6

What we have discovered is that step 3 won't be reached anytime soon 
because too many people are stuck at 1.

So to give people who want to go to 3 for their access, we need them to be 
able to realise 2 by means of v4aaS.

So for me the plan is still "interop between IPv4 and IPv6" but it might 
not be dual stack everywhere, instead it's v4aaS. Because long tail is 
long.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 21 Nov 2017 07:16:49 +0100 (CET)

>> relatively sophisticated users.)

Oh, come on.

For me:

Mosh didn't work (it's single stack once it's connected)
Steam doesn't work (even on Win10). I have no idea how many games do not 
work (because I can't start them), but I'd bet it's A LOT.
Nothing on my corporate VM works (because Parallels does IPv4 NAT, and 
needs to be explicitly configured to be bridged to some NIC/wifi to even 
get the RS on the outside). My VPN doesn't work even if I bridge. Software 
update on Win7 doesn't work on IPv6 only.

These are just things I myself discovered. Yes, getting the VPNs working 
might be a good step (because they'd now be v4aaS) but saying 
v6-only+NAT64 or something, is a viable option in the near future for 
99.9% of users, that's just being silly.

Yes, Jen probably can do it because her employer uses Chrome as its main 
tool for getting anything done. Personally I have in the neighborhood of a 
hundred applications running on my Mac. If I had a windows 7 machine 
as my only environemnt (because enterprise), things would be even worse.

The mass of installed things on devices that need ipv4 literals to work is 
staggering, especially in the long tail. So without bump-in-the-API or 
CLAT, this just won't work in the next 10 years.

---

From: Jen Linkova <[email-masked]>
Date: Tue, 21 Nov 2017 18:05:08 +1100

> 2. IPv6-only hosts are far from universal, even among IETF

What I really wanted to know was exactly how universal those hosts are..

Unfortunately only 33 people have responded to the survey I sent ;( 8
of them said that they can not get their work
done on NAT64 while for the rest it was either "everything worked just
fine" or "smth was broken but not critical" (and yes, there was that
network issue which
affected the user experience..;(

It also showed that some applications which used to be IPv4-only are
now working on NAT64 network.
At least when you run the latest version of the app/the latest version of OSes.

I see it that way: I'm running a network and I do not want to run a
dual-stack one. At least I'd like to minimize IPv4-only/dual-stack
surface.
The fact that there will be some old hosts/apps which could not work
on v4-only network just means that I might not be able
to migrate *all* hosts to v6-only overnight/any time soon.
The same way I still keep 2.4Ghz SSIDs (and some devices using it) in
addition to 5Ghz ones (where majority of devices are sitting).
Number of Ipv4-only applications will go down overtime and eventually
it would not have much sense to maintain them
(as it would be cheaper to get rid of them than maintain dual-stack
only for a few old things..).
When that moment comes for a given network depends on many factors indeed.

> was a very valuable effort.

You are welcome, I'm glad to hear that people find this experiment useful.
All credits goes to the IETF NOC actually, I was just a messenger ;)
(and someone who enjoyed running Wireshark ;))

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 21 Nov 2017 09:36:23 +0100

[Jordi] Just to be clear on this: When I say the hotel CE or AP with CLAT, I mean the same as you – users get in the RJ45/WiFi dual stack (as per today private IPv4 plus global IPv6). The point is that user device doesn’t require anything “new” or “extra”.

    

[Jordi] The fact that some content providers are still not on IPv6, means those contents/services will be slightly slower (NAT64, CGN, etc.), and I guess more and more transit providers will have less incentive to keep the “quality” of the IPv4 path at the same level as the IPv6 one if there is less and less usage. May be some transit providers or ISPs will start charging some extra for IPv4 because the extra cost of maintaining it for a number of users which is going down … I see that already happening in the access for xDSL links vs GPON.

    

[Jordi] sunset4 is IETF. I think we should go that way as soon as possible, because after we have RFCs, it takes at least a couple of years to start flooding into the market. So, we disagree here, we can make IPv4 “somehow” historic in order to do the last push from the technical perspective. Each vendor and ISP will decide, but for example, if there is an RFC, many governments, for public procurement, will consider it, and this is, in turn a pushing factor for vendors and ISPs in that country. From my own experience being contracted by several governments in order to mandate IPv6 support in laws for public procurement, I can tell you that in a matter of months, many other countries took similar decisions looking for the earlier ones, so it becomes a snowball, and at the end it affects also industry and residential users, it just takes time. I’m sure ISOC, ICANN and other organizations will be able to support that “public call” once do our work in sunset4.

    Regards,
       Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 21 Nov 2017 09:39:09 +0100

Hi Masanobu,

Yeah, knew that, but didn’t looked at that web page before, and it looks to me very interesting action for IXs ;-)

There is at least a company that I know, already offering this as a commercial service.

Regards,
Jordi

-----Mensaje original-----
De: Masanobu Kawashima <[email-masked]>
Responder a: <[email-masked]>
Fecha: martes, 21 de noviembre de 2017, 5:11
Para: "[email-masked]" <[email-masked]>, 6man WG <[email-masked]>
Asunto: RE: IPv6 only host NAT64 requirements?

    Hi Jordi, 

    
    
    Regards, 
    Masanobu

---

From: Ola Thoresen <[email-masked]>
Date: Tue, 21 Nov 2017 10:40:13 +0100

> point of view. Operators might not like it, but users wouldn't care.

In hotel rooms and other "public" or "guest" networks, there are so many 
things that fail already, due to NAT, misconfigured firewalls, 
unmaintained blocklists, SSL-proxies and whatnot, so you can hardly 
expect any services other than basic web-surfing without https to work.
Not that this is an ideal situation today, but i do not believe that "if 
even one VPN or one liter IPv4 address fails" should be a showstopper 
for introducing this.
Possibly, or even probably, introducing IPv6 (-only and NAT64) will even 
make the situation better for a lot of people, as you get rid of all the 
horrible NAT solutions for services that are already dual stacked.

Rgds.

Ola Thoresen

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 21 Nov 2017 11:07:14 +0100

I will even say that introducing NAT64+CLAT will solve more problems that if there is NAT+CGN or NAT+CGN+NAT64.

As you indicate, the support for IPv6 will resolve 99.99% of the issues for dual-stacked services and I think NAT64 will improve the % of failures vs CGN+NAT, and if the 464XLAT is properly configured, only a few % of remote IPv4-only-DNSSEC services will fail. 

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Ola Thoresen <[email-masked]>
Responder a: <[email-masked]>
Fecha: martes, 21 de noviembre de 2017, 10:40
Para: <[email-masked]>
Asunto: Re: IPv6 only host NAT64 requirements?

    

    Rgds.
    
    Ola Thoresen

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Nov 2017 13:01:44 +1300

in line...

> even one VPN or one liter IPv4 address fails" should be a showstopper 

Hotels won't make that choice, but the providers of hotel networks will,
entirely based on their perception of the number of help desk calls
they will have to handle for any given change. Since they haven't even
made the move from IPv4 to dual stack, I think we'll wait a long time
before they attempt any form of IPv6-only. Sad but true.

> horrible NAT solutions for services that are already dual stacked.

But those horrible NAT solutions are up and running today. For this
class of operator, any change is bad news, unfortunately. What is their
incentive to make such a change?

    Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 22 Nov 2017 09:05:39 +0100

Le 22/11/2017 à 01:01, Brian E Carpenter a écrit :
> But those horrible NAT solutions are up and running today.

It will be noticed that on NAT64 ESSID the experience is worse than on 
IPv4, at least for VPN sessions.

Alex

  For this

---

From: Ca By <[email-masked]>
Date: Wed, 22 Nov 2017 13:52:44 +0000

On Wed, Nov 22, 2017 at 12:05 AM Alexandre Petrescu <
[email-masked]> wrote:

> >>>> Eat own dogfood. Many IETF people are developers or work for
> companies having applications not working.
> >>>> As I said there were a minimum of applications that didn't work.
> Corporate VPNs largely did. Jen has the final numbers.

How would the vpn service be improved? If the VPN server / peer was ipv6
enabled then it would just be e2e v6, no?

I like to refer back to Occam’s Razor e2e v6 rather than transition Rube
Goldberg

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Nov 2017 14:18:45 +1300

>> Le 22/11/2017 à 01:01, Brian E Carpenter a écrit :

<snip>

> I like to refer back to Occam’s Razor e2e v6 rather than transition Rube

I think we all agree on the long-term fix. The issue seems to be how
we can best (or least badly) deal with legacy hosts and apps that
will be out there for years, generating help desk calls or lost
business.

"Hi! Your hotel group has been removed from our corporate travel
plan because none of our employees can connect to our corporate VPN
from your hotels any more, as confirmed by your WiFi supplier."

   Brian