Subject: Re: RESENDING - Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

From: Mark Andrews <[email-masked]>
Date: Tue, 01 Aug 2017 17:21:39 +1000

In message <[email-masked]>, JORDI PALET M
ARTINEZ writes:
> Hi Med,
>
> In line …
>
> Saludos,
> Jordi
>
>
> -----Mensaje original-----
> De: ietf <[email-masked]> en nombre de
> <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: martes, 1 de agosto de 2017, 8:07
> Para: "[email-masked]" <[email-masked]>,
> "[email-masked]" <[email-masked]>
> Asunto: RE: RESENDING - Incremental Deployment of IPv6-only Wi-Fi for
> IETF Meetings
>
>     Hi Jordi,
>
>     Please see inline.
>
>     Cheers,
>     Med
>
>     > -----Message d'origine-----
>     > De : ietf [mailto:[email-masked]] De la part de JORDI PALET
>     > MARTINEZ
>     > Envoyé : lundi 31 juillet 2017 23:18
>     > À : [email-masked]
>     > Objet : Re: RESENDING - Incremental Deployment of IPv6-only Wi-Fi
>     > for IETF Meetings
>     >
>     > NAT64 was invented for a specific case (when apps use DNS and the
>     > right APIs).
>
>     [Med] This may be misinterpreted as there is a dependency of NAT64 on
> DNS. This is not technically true. This was clarified in
> https://tools.ietf.org/html/rfc6889
>
> [Jordi] Right, I was not pretending to be technically perfect, but
> introducing when NAT64 fails in our network.
>
>        This approach is pragmatic in the sense that there is no dependency
>        on DNS implementation for the successful NAT handling.  As long as
>        there is a function (e.g., DNS64 [RFC6147] or other means) that can
>        construct an IPv6-embedded IPv4 address with a pre-configured IPv6
>        prefix, an IPv4 address and a suffix (refer to [RFC6052]), NAT64
>	 will work just fine.
>
>     FWIW, there are even NAT64 deployments that do not even rely on
> DNS64.
>
> [Jordi] Agree, we can talk about “DNS64 function” instead of DNS64.
> Again, in our IETF network there is a DNS64, so not the issue here.
>
>     >
>     > We realized then that app/devices vendors are lazy, or just they
>     > are out of the market, so we invented 464XLAT, which uses the same
>     > concept as
>     > NAT64/DNS64, but improves it by using the CLAT, a small daemon code
>     > in the
>     > OS or the CPE to solve the problems of the literal addresses and
>     > non-APIs
>     > apps/devices.
>     >
>     > We don’t need to tell the customers to disable IPv4 in their LANs,
>     > we need
>     > to make sure that we deploy CPEs that support CLAT.
>
>     [Med] Is there any CPE-based 464xlat deployment out there?
>
> [Jordi] I’ve identified 4 vendors up to now, with different products
> each. I’m sure there are more. I also know that other vendors did the
> development for specific customers and I’m also aware of other customers
> that asked for it. We have also the open source implementations, such as
> OpenWRT, supporting thousands of devices. Precisely this is my point. As
> IETF, our work is not just inventing transitions mechanism, but also
> making sure that if we state a set of requirements for CPEs, we include
> the support for those transition mechanisms.

People ask for lots of things and even write code.  That doesn't mean
that the thing they ask for is actually good or there is not something
better.  This IETF should be recommending what is actually best.

>     > This way, users don’t
>     > need to throw away old devices or apps, neither learn anything
>     > about IPv4
>     > or IPv6, and everybody is happy.
>     >
>     > We are trying to solve a problem with NAT64 which we knew
>     > since it was invented that it can’t be solved. We don’t have
>     > the time (unless some magic is discovered) to now tell every
>     > ISP that is deploying IPv6 and NAT64, to instead of NAT64
>     > have something different.
>
>     [Med] These operators (with CPEs) are already doing something
> *different*: DS-Lite and the like. NAT64 is widely deployed in cellular
> networks (host-based model), which is really straightforward.
>
> [Jordi] I agree, but if you have a network with cellular and wireline
> access, you may want to have a single transition mechanisms instead of
> two. If we don’t want to use NAT64 in wireline, then why we are trying to
> push it as the default SSID in our IETF network?

Because that's what everyone TALKS about.  NAT64 was sexy.

If we were being honest with ourselves we would do NAT64, then
DS-Lite, then MAP at consecutive IETFs and release a recommendation
for wireline deployments based off the experience or at least a
report on the issues found.

> It is a matter of
> preference of one or another transition mechanisms. All them have good
> and bad things. I see much simpler the combination of NAT64+CLAT than
> DS-Lite or MAP, in addition to the ONLY support in cellular networks is
> precisely NAT64/464XLAT, which means is the MOST extended transition
> mechanism by millions (billions?) of users. It makes a lot of sense to me
> to go in all the infrastructures to the one that has more deployment
> already.

Not really.  Cellular networks went with anything available, rather
than the best.  We are continuing the pay the price for that.

>     > The solution is
>     > there, if CPE vendors implement it, and we are talking about an
>     > available
>     > open source code (several implementations) that take a few bytes.
>     >
>     > We are already doing this effort in v6ops, I started trying to tell
>     > the RFC7084 about the need to update it, but didn’t succeeded. It
>     > seems that now we may want to have instead of a CPE requirements
>     > including this, an additional document to be a must for CPE vendors
>     > to support it, in case the CPE expects “IPv4 old devices and apps”
>     > in the LANs (which is real world life, and will be for 3-5 years).
>
>     [Med] I'm afraid we don't need it. The IETF already specified tools
> to address that case (DS-Lite, MAP-E).
>
> [Jordi] I guess no need to repeat myself …
>
>
>     >
>     > Regards,
>     > Jordi
>     >
>     >
>     > -----Mensaje original-----
>     > De: ietf <[email-masked]> en nombre de Ole Jacobsen
>     > <[email-masked]>
>     > Responder a: Ole Jacobsen <[email-masked]>
>     > Fecha: lunes, 31 de julio de 2017, 23:01
>     > Para: Ted Lemon <[email-masked]>
>     > CC: <[email-masked]>
>     > Asunto: Re: RESENDING - Incremental Deployment of IPv6-only Wi-Fi
> for IETF
>     > Meetings
>     >
>     >
>     >     You said:
>     >     >
>     >     > Brian, why on earth would we want to advertise IPv6 to IETF
>     >     > attendees?  We invented IPv6.  If we really can't run a
> v6-only
>     >     > network at IETF, what that says is that we have failed
> utterly and
>     >     > expensively.  I do not believe that this is correct: IPv6
> works very
>     >     > well.
>     >
>     >     Putting on my naive end-user hat:
>     >
>     >     That might be true, but here is the thing: "The mission of the
> IETF is
>     >     to make the INTERNET work better..." (my emphasis)
>     >
>     >     For at least a decade now, I've been told that I should "just
> use
>     >     IPv6" and some conferences have even "forced" me to do so.
>     >
>     >     I always respond with this question: "Does running IPv6 allow
> me to
>     >     connect to the Internet?" (meaning the v4 Internet for the most
> part).
>     >     The answer always seems to be: "Yes, but you have to manually
>     >     configure this and, oh by the way, this won't work at all and
> that app
>     >     might not behave as expected."
>     >
>     >     Demonstrating this to people who are experts seems like a waste
>     >     of time.
>     >
>     >     So it sounds to me like we HAVE indeed failed utterly and
> expensively.
>     >     99% of Internet users do not have any idea what version of IP
> they are
>     >     running just as they have no idea what a MAC address is or
> why/if they
>     >     should care.
>     >
>     >     I'd love to see IPv6 succeed, but it is apparently impossible
> to do so
>     >     without teaching end-users a lot of stuff they really have no
> interest
>     >     in or ability to learn. What a shame.
>     >
>     >     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 use of the
>     > individual(s) named above. If you are not the intended recipient be
> aware
>     > that any disclosure, copying, distribution or use of the contents
> of this
>     > information, including attached files, is prohibited.
>     >
>     >
>
>
>
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the use of the
> individual(s) named above. If you are not the intended recipient be aware
> that any disclosure, copying, distribution or use of the contents of this
> information, including attached files, is prohibited.
>
>
>

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

---

From: <[email-masked]>
Date: Tue, 1 Aug 2017 07:53:15 +0000

Hi Mark, 

Answering this particular point. 

Please see inline. 

Cheers,
Med

> De : ietf [mailto:[email-masked]] De la part de Mark Andrews
> Envoyé : mardi 1 août 2017 09:22
> À : [email-masked]
> Cc : [email-masked]
> Objet : Re: RESENDING - Incremental Deployment of IPv6-only Wi-Fi for IETF
> Meetings
> 
> 

[Med] Actually, no. There was an IPv6 Study Item within 3GPP. Both DS-Lite, A+P, and NAT64 were presented and documented in a 3GPP report. For example, this is what was documented for A+P:

Known issues:
-	The UE needs to be modified to support A+P scheme
-	The gateway needs to forward not only based on IP address but based on address plus port. The network needs to implement PRR in similar places as CGN in the DS-Lite approach
-	The backend RADIUS system needs to be changed as subscribers can no longer be identified by IP address only, but by IP address and port
-	In the IPv6 tunnelling approach QoS differentiation between bearers cannot be provided easily
-	The solution works only with applications using transport protocols, which have concept of port numbers (such as UDP and TCP). There will be challenges with protocols which use plain IP.
-	The solution sets restrictions to applications within in the UE, as the allocation of fixed port numbers becomes more complicated.
-	For ICMP messages, the UE must use an ICMP query identifier within the allocated port range, otherwise the response will not be received by this UE.

Known benefits:

-	The UE has access to public IPv4 address, which simplifies the behaviour for P2P applications such as VoIP.
-	Allows IPv4 lifetime extension if used with GTP/GRE.
-	Legal requirements for tracing which traffic flow was originated from which UE is simpler than in CGN solutions, as the operator does not need to store each flow but only A+P allocation information.
-	In GTP/GRE/DSMIP6 based solutions QoS can be provided.
-	A+P allows for an incremental migration to IPv6-only network
-	A+P can be fully stateless when used together with IPv6
-	No per-state sessions are maintained in the PLMN realm
-	Unlike NAT44/NAT64, no dynamic state synchronization is required to ensure service robustness
-	No ALG is required to be implemented in the service/PLMN realm
-	No extra-cost on the UE to support NAT traversal techniques is required
-	Unlike double NAT solutions, peer-to-peer services can be delivered with one exception as documented in [23]
-	No Keep-alive messages are required to maintain NAT entries. This characteristic mitigates battery consumption issues induced by "Always-on" services. Especially, the use of short intervals between keep-alive messages has a big impact on the battery consumption (See [24] for more details about complications to tweak UDP timers in NAT devices and also keep-alive intervals used by UE). Moreover, the network load is more optimized since the load induced by keep-alive messages in the context of CGN solutions is avoided.
-	Latencies and related problems of NATs are avoided. 

And for NAT64:

==
Known issues of the solution:

-	The session binding between MS/UE IPv6 address and public IPv4 address/port is not known to the PCC architecture. Therefore, depending on deployment and if the application is NAT aware and has access to the binding (as e.g. in the case of IMS), there may or may not be issues with applying PCC to the session.
-	General NAT concerns, not specific to 3GPP networks, apply. For example, applications that embed IP addresses in the payload and are not NAT aware require additional functionality to work across NATs.
-	In case of roaming with Local Breakout (PGW/GGSN in VPLMN), if there is a need to reach IPv4-only services, the VPLMN operator would be required to deploy NAT64/DNS64 in order to provide the same user experience using IPv6-only connections for IPv4-only services as in non-roaming scenarios.
-	It is unclear how IPv4 literals are supported.

Known benefits of the solution

-	This solution requires no changes to the MS/UE.
-	The existing bearer and session management procedures can be used without any change.
-	This solution does not introduce any additional tunnelling overhead on any interfaces.
-	This solution has no impact to the 3GPP network architecture, no new interface or network element is needed. This solution can be deployed without any additional normative specification within 3GPP. Limitations described under "known issues" above apply.
-	No changes to the IPv6 address-assignment procedures required.
-	No bearing on the type of transport network: Transport network can be IPv4 or IPv6.
-	NAT64 can be either co-located or separate from GGSN/PDN-GW.
-	Solution to the public IPv4 address exhaustion problem through the use of stateful NAT64.
-	No impact on QoS/bearer procedures between UE and PDN GW/S GW.
===

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 01 Aug 2017 10:15:10 +0100

> better.  This IETF should be recommending what is actually best.

"actually best"?

What a curious idea.

Nick

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 01 Aug 2017 11:56:20 +0200

And in general, many of those considerations from 3GPP are equivalent in wireline networks (except for specific 3G items, of course).

And the NAT64 issue:

Is precisely what CLAT (464XLAT) is resolving.

Regards,
Jordi

-----Mensaje original-----
De: ietf <[email-masked]> en nombre de <[email-masked]>
Responder a: <[email-masked]>
Fecha: martes, 1 de agosto de 2017, 9:53
Para: Mark Andrews <[email-masked]>, "[email-masked]" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: RE: RESENDING - Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    Hi Mark, 

    Please see inline. 
    
    Cheers,
    Med

    
    Known issues:
    
    Known benefits:

    And for NAT64:
    
    ==

    

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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 01 Aug 2017 12:09:02 +0200

Fully agree with you in one specific point:

If we try NAT64, we should also try DS-Lite, MAP-T, MAP-E, lw4o6, 464XLAT, and all the others …

We all agree with that? NOC guys will love us! Irony mode off/

Precisely my point is to use what is “best” in “most” of the situations.

CLAT is the ONLY one that works in mobile networks. Works also in wireline. Is no breaking apps and devices that user literals or don't use APIs.

Today hosts (laptops, tablets, smartphones), some times are used in wireline (or WiFi) networks, sometimes are used in cellular network (either directly attached if they have a 3G/LTE interface or with tethering). SO, it makes a lot of sense that all hosts have CLAT support (and Windows 10 has included it in the last update), it is a very lightweight daemon, is not something complex at all.

If we have it also in CPEs, then we are covering all the possible scenarios also for old devices apps or desktop computers in those LANs.

I think it makes a lot of sense and it is the “best” balanced solution, which is what you are suggesting, right?

Regards,
Jordi

-----Mensaje original-----
De: Mark Andrews <[email-masked]>
Responder a: <[email-masked]>
Fecha: martes, 1 de agosto de 2017, 9:21
Para: <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: Re: RESENDING - Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    ARTINEZ writes:
    > In line â•œ
    >     > EnvoyÃ© : lundi 31 juillet 2017 23:18
    >     > Ã• : [email-masked]
    > [Jordi] Agree, we can talk about â•˛DNS64 functionâ•ˇ instead of DNS64.
    >     > We donâ•˙t need to tell the customers to disable IPv4 in their LANs,
    >     > we need
    > [Jordi] Iâ•˙ve identified 4 vendors up to now, with different products
    > each. Iâ•˙m sure there are more. I also know that other vendors did the
    > development for specific customers and Iâ•˙m also aware of other customers

    >     > This way, users donâ•˙t
    >     > since it was invented that it canâ•˙t be solved. We donâ•˙t have
    > two. If we donâ•˙t want to use NAT64 in wireline, then why we are trying to

    

    >     > the RFC7084 about the need to update it, but didnâ•˙t succeeded. It
    >     > to support it, in case the CPE expects â•˛IPv4 old devices and appsâ•ˇ
    > [Jordi] I guess no need to repeat myself â•œ
    >
    >
    >     >
    >     > Regards,
    >     > Jordi
    >     >
    >     >

---

From: Philip Homburg <[email-masked]>
Date: Tue, 01 Aug 2017 12:34:02 +0200

>Is precisely what CLAT (464XLAT) is resolving.

So we have a standard way of delivering IPv4 over wifi. It actually works.
It is used by billions of people every day without even thinking about it.
By all measures a great success.

We also have a way of delivering IPv6 over wifi. In typical IETF fashion 
we try to break that as much as possible. But it can be made to work.

So obviously this is way too boring. We have both IPv4 and IPv6 that work.
We need to do something, anything.

So NAT64 enters the stage. At first NAT64 was used to solve a problem in
the mobile networks where you cannot have dual stack for reasons only telco's 
understand.

But now we can use that same technology to spice up the wifi landscape a bit
more.

First we confusingly call it 'IPv6-only'. There is nothing IPv6-only about
NAT64. It is a technology specifically designed to provide access to the
IPv4 world.

Then, because of the fancy name 'IPv6-only' we claim it is the future. No
need to justify why modifying all hosts and making the whole system more
complex would be a reasonable future.

We have something that works today. We have plenty of experience delivering
what works today. No need to push overly complex technologies that offer
nothing more than a fancy name. That's not engineering, that's a hobby.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 01 Aug 2017 12:39:40 +0200

Just small clarifications in-line.

Saludos,
Jordi

-----Mensaje original-----
De: ietf <[email-masked]> en nombre de Philip Homburg <[email-masked]>
Responder a: <[email-masked]>
Fecha: martes, 1 de agosto de 2017, 12:34
Para: <[email-masked]>
CC: JORDI PALET MARTINEZ <[email-masked]>
Asunto: Re: RESENDING - Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    

[Jordi] Because we don’t have any more IPv4 public addresses, and we know that for some time, we will need to access still some old “IPv6-only” resources? Sharing IPv4 addresses by means of NAT64 is one solution to that.

    

[Jordi] Agree, see: https://tools.ietf.org/html/draft-palet-ietf-v6ops-ipv6-only-00

[Jordi] We need to move to IPv6-only “all”, there is an intermediate step, for “some” (crystal ball) years, which is IPv6-only-WAN, but dual-stack in the LAN. NAT64+CLAT provides it seamless across both wireline, WiFi and cellular networks.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 1 Aug 2017 09:15:31 -0400

> We need to do something, anything.

Yes, Philip.   The reason we are having this discussion is that a bunch of us were bored and wanted to see if we could get a rise out of the IETF by proposing something with no good purpose, just to kill the boredom.   None of us have any other work to do.   Hell, that's why we invented IPv6 in the first place, and IPv4 too.   POTS was working fine.   And remember chaosnet and SNA?   Those kicked ass!   We were just bored.

Honestly, though, it's been a blast.   I don't see why you are being such a killjoy.   What's wrong with hobbies?

Seriously, my point is that the tone of your message and quite a few others here is that people who think this proposal is worthwhile are hobbyists, and people who think it's not are Serious People Trying To Get Work Done.   I'm sure it's a satisfying narrative, but it's kind of absurd.

If there's consensus to do this, we should do it.   If there isn't, we shouldn't.   That's how the IETF is supposed to work.   A little less contempt would go a long way to preventing conversations like this from blooming into the hundreds of messages.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Aug 2017 00:58:49 +1000

In message <[email-masked]
ot.infra.ftgroup>, [email-masked] writes:
> > De: ietf mailto:[email-masked] De la part de Mark Andrews
> > Envoy: mardi 1 aot 2017 09:22
> > : [email-masked]
> > Cc: [email-masked]
> > Objet: Re: RESENDING - Incremental Deployment of IPv6-only Wi-Fi for
> IETF
> > Meetings
> >
> >
> > > In line
> Med Actually, no. There was an IPv6 Study Item within 3GPP. Both DS-Lite,
> A+P, and NAT64 were presented and documented in a 3GPP report. For
> example, this is what was documented for A+P:
>
> Known issues:
> -	The gateway needs to forward not only based on IP address but
> based on address plus port. The network needs to implement PRR in similar
> places as CGN in the DS-Lite approach
> -	The backend RADIUS system needs to be changed as subscribers can
> no longer be identified by IP address only, but by IP address and port
> -	The solution works only with applications using transport
> protocols, which have concept of port numbers (such as UDP and TCP).
> There will be challenges with protocols which use plain IP.
> -	The solution sets restrictions to applications within in the UE,
> as the allocation of fixed port numbers becomes more complicated.
> -	For ICMP messages, the UE must use an ICMP query identifier
> within the allocated port range, otherwise the response will not be
> received by this UE.
>
> Known benefits:
>
> -	The UE has access to public IPv4 address, which simplifies the
> behaviour for P2P applications such as VoIP.
> -	Legal requirements for tracing which traffic flow was originated
> from which UE is simpler than in CGN solutions, as the operator does not
> need to store each flow but only A+P allocation information.
> -	Unlike double NAT solutions, peer-to-peer services can be
> delivered with one exception as documented in 23
> -	No Keep-alive messages are required to maintain NAT entries. This
> characteristic mitigates battery consumption issues induced by
> "Always-on" services. Especially, the use of short intervals between
> keep-alive messages has a big impact on the battery consumption (See 24
> for more details about complications to tweak UDP timers in NAT devices
> and also keep-alive intervals used by UE). Moreover, the network load is
> more optimized since the load induced by keep-alive messages in the
> context of CGN solutions is avoided.
> -	The session binding between MS/UE IPv6 address and public IPv4
> address/port is not known to the PCC architecture. Therefore, depending
> on deployment and if the application is NAT aware and has access to the
> binding (as e.g. in the case of IMS), there may or may not be issues with
> applying PCC to the session.
> -	General NAT concerns, not specific to 3GPP networks, apply. For
> example, applications that embed IP addresses in the payload and are not
> NAT aware require additional functionality to work across NATs.
> -	In case of roaming with Local Breakout (PGW/GGSN in VPLMN), if
> there is a need to reach IPv4-only services, the VPLMN operator would be
> required to deploy NAT64/DNS64 in order to provide the same user
> experience using IPv6-only connections for IPv4-only services as in
> non-roaming scenarios.

Requires EVERY DNSSEC validator on the planet to learn about DNS64.

DS-Lite does NOT require every DNSSEC validator on the planet to
be upgraded.

> -	The existing bearer and session management procedures can be used

Since you are sending IPv4 as IPv6 there is no difference between NAT64
and DNS-Lite etc.

> overhead on any interfaces.

You have 1480 payloads with NAT64 and 1460 byte playloads with DS-Lite etc.
Incoming 1500 byte IPv4 packets get fragmented either way as they can't
fit in a 1500 byte IPv6 packet.

> -	This solution has no impact to the 3GPP network architecture, no
> new interface or network element is needed. This solution can be deployed
> without any additional normative specification within 3GPP. Limitations
> described under "known issues" above apply.

None required for DS-Lite either.

> -	NAT64 can be either co-located or separate from GGSN/PDN-GW.

Same with DS-Lite.

> the use of stateful NAT64.

Same with DS-Lite (stateful NAT again).

> -	No impact on QoS/bearer procedures between UE and PDN GW/S GW.

DS-Lite does NOT require every node on the planet to aquire a CLAT
only a encapsulating interface to talk to legacy devices.

When you ignore some of the problem space NAT64 looks ok.  When you
look at the entire problem space that is not the case.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 1 Aug 2017 11:08:15 -0400

> Requires EVERY DNSSEC validator on the planet to learn about DNS64.

Just to be clear, every DNSSEC validator on the planet also had to learn about DNSSEC, so it's probably worth explaining why this is a problem: the problem is not that we'd have to update every DNSSEC validator, but rather that this makes DNSSEC validators more complicated, and that potentially comes with problems, and that code will just be extra most of the time, perhaps.

Although in practice I suspect that as time goes on and more providers adopt IPv6, there will come a time when NAT64 will be very much the most economical solution to dealing with the long tail of small IPv4 service providers.   And I think if you impose functional separation between validation and translation, you don't create a serious risk.

But I think the point you make is valid, and I don't claim to be authoritative on the topic of how risky this is.

---

From: Tim Chown <[email-masked]>
Date: Tue, 1 Aug 2017 18:28:11 +0100

> On 1 Aug 2017, at 16:08, Ted Lemon <[email-masked]> wrote:
> 

Apologies if it was already mentioned, but this was a good read:

https://blog.apnic.net/2016/06/09/lets-talk-ipv6-dns64-dnssec/

Tim

---

From: "John Levine" <[email-masked]>
Date: 1 Aug 2017 17:34:21 -0000

In article <[email-masked]> you write:
>Yes, Philip.   The reason we are having this discussion is that a bunch of us were bored and wanted to see if we could get
>a rise out of the IETF by proposing something with no good purpose, just to kill the boredom.

It certainly worked, didn't it?

HTH, HAND,
John

---

From: Ted Lemon <[email-masked]>
Date: Tue, 1 Aug 2017 13:57:11 -0400

> Apologies if it was already mentioned, but this was a good read:

Yes, she describes the issue nicely.   What she doesn't mention is that there is a way to detect DNS64, so in principle a validating stub resolver can do DNS64 itself _post validation_.   Of course, there are a lot of moving parts in this, particularly if you have multiple stub resolvers per host (e.g., a stub resolver in your browser and another one in your libc).

But the point is that it is actually possible to have NAT64 and DNSSEC.   And indeed, if you are able to detect the NAT64 prefix (RFC 7050), you can treat all IPv4 addresses as IPv6 addresses by prepending the NAT64 prefix in the stack, and you don't even need to do DNS64 in the resolver, so validation just works (RFC 6535).

You can also do this by doing IPv4-to-v6 translation in the router, which is what Jordi is talking about when he mentions CLAT (RFC6877).

The only reason I'm not on board with Jordi's proposal is that I think it's more interesting to see what stacks do when you don't give them _any_ IPv4 address.   But in principle, with Jordi's solution, even IPv4 literals are handled correctly, and the interactions between DNS64 and VPNs go away as well.   To me this seems like a pretty reasonable compromise position, although it's not the experiment I'd personally prefer to run.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 1 Aug 2017 14:14:53 -0400

On Aug 1, 2017, at 1:57 PM, Ted Lemon <[email-masked]> wrote:
> What she doesn't mention is that there is a way to detect DNS64, so in principle a validating stub resolver can do DNS64 itself _post validation_.

Oops, actually she did mention that in the last paragraph—sorry!

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Aug 2017 09:26:51 +1000

In message <[email-masked]>, Ted Lemon writes:
> > What she doesn't mention is that there is a way to detect DNS64, so in
> principle a validating stub resolver can do DNS64 itself _post
> validation_.
>

You have to detect it and work around it.

NAT64 start out with the claim "You don't have to touch the node".

Now you have complicated CLAT and DNSSEC changes required in every
node in the internet to support NAT64 with more breakage than simple
tunneling and a NAT44 protocol translation in DS-Lite.  What's the
next workaround that will have to be deployed because NAT64 is being
used instead of NAT44 at the end of the tunnel?

CLAT and DNSSEC changes are required on every node as they will end
up on IPv6-only networks.  DS-Lite also requires changes on every
node on IPv6-only networks but they are much less intrusive.

We have created Frankenstein's monster here with NAT64.

Mark

---

From: Ted Lemon <[email-masked]>
Date: Tue, 1 Aug 2017 21:05:52 -0400

Actually CLAT+NAT64 doesn't require changes on the node.   I don't disagree
with the rest of what you said (aside from the Frankenstein's monster bit:
Frankenstein's monster was really misunderstood).

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Aug 2017 11:38:06 +1000

In message <[email-masked]>, Ted Lemo
> Frankenstein's monster was really misunderstood).

It does for IPv6-only if want to talk to IPv4 literals or talk to
IPv4 only services when you are validating DNS answers.  You may
be thinking about DS local + IPv6 only uplink where you have the
CLAT on the router (which is the configuration that is being proposed
for ietf ssid).  Real IPv6 only networks don't have IPv4 traffic
on the wire, just inside the node.

Mark

> > > > What she doesn't mention is that there is a way to detect DNS64, so i=
> n
> > > Oops, actually she did mention that in the last paragraph=E2=80=94sorry=
> !
> >
> --94eb2c0de54cf091f30555badf94
> Content-Type: text/html; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr">Actually CLAT+NAT64 doesn&#39;t require changes on the nod=
> e. =C2=A0 I don&#39;t disagree with the rest of what you said (aside from t=
> he Frankenstein&#39;s monster bit: Frankenstein&#39;s monster was really mi=
> sunderstood).</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
> ">On Tue, Aug 1, 2017 at 7:26 PM, Mark Andrews <span dir=3D"ltr">&lt;<a hre=
> f=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</span> w=
> rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
> r-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D=
> "h5"><br>
> In message &lt;<a href=3D"mailto:30708801-142F-47C5-A154-15E9D3C5068D@fugue=
> .com">30708801-142F-47C5-A154-<wbr>[email-masked]</a>&gt;, Ted Lemo=
> n writes:<br>
> &gt;<br>
> &gt; On Aug 1, 2017, at 1:57 PM, Ted Lemon &lt;<a href=3D"mailto:mellon@fug=
> ue.com">[email-masked]</a>&gt; wrote:<br>
> &gt; &gt; What she doesn&#39;t mention is that there is a way to detect DNS=
> 64, so in<br>
> &gt; principle a validating stub resolver can do DNS64 itself _post<br>
> &gt; validation_.<br>
> &gt;<br>
> &gt; Oops, actually she did mention that in the last paragraph=E2=80=94sorr=
> y!<br>
> <br>
> </div></div>You have to detect it and work around it.<br>
> <br>
> NAT64 start out with the claim &quot;You don&#39;t have to touch the node&q=
> uot;.<br>
> <br>
> Now you have complicated CLAT and DNSSEC changes required in every<br>
> node in the internet to support NAT64 with more breakage than simple<br>
> tunneling and a NAT44 protocol translation in DS-Lite.=C2=A0 What&#39;s the=
> <br>
> next workaround that will have to be deployed because NAT64 is being<br>
> used instead of NAT44 at the end of the tunnel?<br>
> <br>
> CLAT and DNSSEC changes are required on every node as they will end<br>
> up on IPv6-only networks.=C2=A0 DS-Lite also requires changes on every<br>
> node on IPv6-only networks but they are much less intrusive.<br>
> <br>
> We have created Frankenstein&#39;s monster here with NAT64.<br>
> <span class=3D"HOEnZb"><font color=3D"#888888"><br>
> Mark<br>
> </font></span><div class=3D"HOEnZb"><div class=3D"h5">--<br>
> Mark Andrews, ISC<br>
> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
> PHONE: <a href=3D"tel:%2B61%202%209871%204742" value=3D"+61298714742">+61 2=
>  9871 4742</a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
> =A0INTERNET: <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> </div></div></blockquote></div><br></div>
> 
> --94eb2c0de54cf091f30555badf94--

---

From: Ted Lemon <[email-masked]>
Date: Tue, 1 Aug 2017 21:42:57 -0400

On Aug 1, 2017, at 9:38 PM, Mark Andrews <[email-masked]> wrote:
> IPv4 only services when you are validating DNS answers.

I'm talking about when you have CLAT in the router.

---

From: <[email-masked]>
Date: Wed, 2 Aug 2017 05:51:42 +0000

Mark,

It seems that you missed my point (or I wasn't that clear). 

I was answering to your claim that "Cellular networks went with anything available". That claim is not true at all. I provided you with details about what was happening since 2010 when all the documents we are talking about, are IETF drafts (dome of them are individual drafts such as A+P). Public reports are available.  

What is important to note is there is some kind of consensus to proceed with NAT64 if you only assign IPv6 prefix to mobile handsets. That's really important for the industry instead of fragmenting required features on the handsets.  

Issues are known and documented for NAT64 (e.g., RFC6889, Section 3 of RFC 7051). Some of the issues are not specific to NAT64, but apply to any IPv4 service continuity flavor (RFC6269). Solutions are documented for some of the issues (RFC7050, RFC7225, ...).

You may disagree with the analysis, but all the proposals were on the table and none of them was available in term of "stable" product at that time. We worked with vendors on both Ds-Lite and NAT64 when these technologies are not RFCed yet.  

I agree that some of the issues do not apply for DS-Lite, and some of the DS-Lite implications on the mobile handset are removed if Gi-DS-Lite is enabled (RFC6674) but 6674 comes with its own set of issues that were analyzed too. 

Cheers,
Med

> De : Mark Andrews [mailto:[email-masked]]
> Envoyé : mardi 1 août 2017 16:59
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [email-masked]; [email-masked]
> In message
> <[email-masked]
> > > In message <[email-masked]>,
> JORDI
> > > PALET M
> > > ARTINEZ writes:
> > > > Hi Med,
> > > >
> > > > In line
> > > >
> > > > Saludos,
> > > > Jordi
> > > >
> > > >
> > >
> > > > It is a matter of
> > > > mechanism by millions (billions?) of users. It makes a lot of sense
> to
> > > me

---

From: Philip Homburg <[email-masked]>
Date: Wed, 02 Aug 2017 10:45:04 +0200

>I'm talking about when you have CLAT in the router.

Maybe we can have all discussion about CLAT on the router under this 
subject?

Is there any experience with this? Did previous IETF meetings have an
experimental SSID with this setup?

I'm certainly not opposed to having the router do some sort of tunneling.
Whether it is CLAT+NAT64 or MAP-E, MAP-T. DS-Lite or what have you.

As long it provides hosts with the illusion of CGN IPv4-NAT then that's
probably the best you can expect in most places.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 02 Aug 2017 10:48:34 +0200

In the Chicago (IETF 98), I’ve been allocated a /64 so I can run my own CLAT in my laptop (I was doing it either by means of a VM with OpenWRT or a VM with Ubuntu and Jool).

It was working perfectly.

Of course, I’ve tried that in other scenarios, including some thousands of CPEs in customer networks.

Regards,
Jordi

---

From: Christian Huitema <[email-masked]>
Date: Wed, 2 Aug 2017 06:56:36 -0700

> Of course, I’ve tried that in other scenarios, including some thousands of CPEs in customer networks.

I have no doubt that a combination of IPv6 native and network provided
CLAT will work. It effectively provides devices with a dual stack
service, native IPv6 and natted IPv4. We know that dual stack works --
it has been the default service on the main IETF network for years. We
also know that natted IPv4 kind of works -- that's what most customers
have been getting for many years, and most applications have adapted by now.

But then, why deploy that on the main IETF network? IPv6 plus natted
IPv4 is definitely less cool than IPv6 plus native IPv4, which is what
the network has traditionally provided.

-- Christian Huitema

-- 
Christian Huitema

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 02 Aug 2017 16:10:04 +0200

Because that is the “closer” thing we are going to get in the user and corporate networks in the next few years.

IETF has not used before IPv4-NAT, so yes, is less cool, but is more *real world* and if we want to make sure that users don’t get into troubles, we should get that dogfood.

By the way, I’m starting to think that before continuing this discussion, we should understand (and the NOC folks are probably the right ones to confirm) if we still believe that the main SSID should be a stable production network or open to trying things …

I asked a few emails ago, what is our target with any change in the main SSID, for example:
1) Try real world (real world has IPv4 behind NAT), using for example CLAT, so the WAN can be IPv6-only
2) Try IPv6-only in the LAN, which we know many things will fail if they use literal IPv4 addresses
3) Something else?
4) Marketing “hey we are the IETF, we use IPv6-only, everything works” which can never be true, because if anyone has an IPv4 only device or app, will not work … It is better marketing to make sure that CPEs and OS support CLAT so nothing gets broken?

Is the reason to report to app/developers what is broken? Who is going to report that?

Can we enforce them to sort it out? If the answer is not, then it makes sense to ensure that we have mechanisms such as CLAT to avoid users get broken things, right?

If we want to try broken apps, is the IETF the right network or we should look for app/developers conferences?

Regards,
Jordi

-----Mensaje original-----
De: ietf <[email-masked]> en nombre de Christian Huitema <[email-masked]>
Responder a: <[email-masked]>
Fecha: miércoles, 2 de agosto de 2017, 15:57
Para: <[email-masked]>
Asunto: Re: Incremental Deployment of CLAT on the router for IETF Meetings

    

    -- Christian Huitema

    -- 
    Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Wed, 2 Aug 2017 07:43:34 -0700

> 4) Marketing “hey we are the IETF, we use IPv6-only, everything works” which can never be true, because if anyone has an IPv4 only device or app, will not work … It is better marketing to make sure…
The actual goal of the main IETF network? From the beginning, it has
been "provide the best possible Internet connectivity to IETF
participants." Which for us today means dual stack, native IPv4 and
IPv6, and high bandwidth. That message was repeated quite loudly on the
list. The rough consensus is that any experiment should be opt-in, on a
separate network.

Would that change some day? Yes, very possibly, because of evolving
infrastructure and costs. We could see a situation where providing
native IPv4 connectivity is becoming too hard, or too expensive. If that
happened today, switching to IPv6 plus CLAT would make sense. I assume
that this is a long way from happening, but I have not seen the break
down of the costs.

As for the marketing statement today, it is simple. We do use IPv6 in a
dual stack configuration. Dual stack has been the official IPv6
transition strategy for years, so there is really nothing wrong in
saying that the IETF uses it.

-- Christian Huitema

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 02 Aug 2017 16:51:45 +0200

Then I guess we fully agree, and I believe I was the first one reminding that our network is a production one …

As we already had a NAT64 SSID for some time, the right step for IETF100 will be then to have a CLAT SSID, so it can be tested by those folks that want to test it.

I’m happy to help the NOC team to do that if they need help.

Regards,
Jordi

-----Mensaje original-----
De: ietf <[email-masked]> en nombre de Christian Huitema <[email-masked]>
Responder a: <[email-masked]>
Fecha: miércoles, 2 de agosto de 2017, 16:44
Para: <[email-masked]>
Asunto: Re: Incremental Deployment of CLAT on the router for IETF Meetings

    

    -- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Wed, 2 Aug 2017 08:04:00 -0700

> I’m happy to help the NOC team to do that if they need help.

That would be good, especially if the CLAT network did NOT include any
DNS64 function. There is a growing suspicion that hacking the DNS in the
name of IPv6 transition was a really bad idea. we have heard it many
times -- breaking DNSSEC, not working with VPN, or Netflix, or Skype.
Also, we know that a large fraction of DNS query are served by Google
DNS and other global providers, which means that the DNS64 hacking
server will not see them. So, if we could demonstrate that DNS64 is not
needed for transition, that would be great.

-- Christian Huitema

-- 
Christian Huitema

---

From: Michael Breuer <[email-masked]>
Date: Wed, 2 Aug 2017 22:00:11 +0200

> NAT64. It is a technology specifically designed to provide access to the

To me it seems there is a lot of confusion and mixing up IPv6-only and
NAT64, but at least for the IETF network they are two different
networks. On https://tickets.meeting.ietf.org/wiki/IETF99network the
ssid *ietf-v6ONLY* is described as "v6 only" and the ssid *ietf-nat64*
in contrast as "v6 with NAT64 & DNS64".

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Aug 2017 08:44:33 +1200

> needed for transition, that would be great.

Yes. The fact of life is that most of us live with NAT44 anyway; I don't
like it, but there is nothing I do regularly that is broken by NAT44.
I'd be mildly disturbed if the IETF SSID offered Net 10, but I'm sure
it would work nicely. If the back end was CLAT, how would I even know?

   Brian

---

From: <[email-masked]>
Date: Thu, 3 Aug 2017 05:45:30 +0000

Christian, 

I will focus on this part of your message:

"So, if we could demonstrate that DNS64 is not
needed for transition, that would be great."

Actually, we don't need to demonstrate that given that NAT64 specification does not make any assumption how IPv4-converted IPv6 addresses are formed. We hoped this was clarified in RFC6889. 

But if you need a concrete example, there are deployments in which DNS64 is not used to synthesize addresses. You can refer to this prez:
https://www.youtube.com/watch?v=o2_7By2EgSY (1mn30)

Cheers,
Med

> De : ietf [mailto:[email-masked]] De la part de Christian Huitema
> Envoyé : mercredi 2 août 2017 17:04
> À : [email-masked]
> Objet : Re: Incremental Deployment of CLAT on the router for IETF Meetings
> 
> 
> 
> > As we already had a NAT64 SSID for some time, the right step for IETF100
> will be then to have a CLAT SSID, so it can be tested by those folks that
> want to test it.
> >

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 03 Aug 2017 10:01:04 +0200

And I can confirm that yesterday I did some testing about this, with the same VMs that I’ve used in the IETF98, and as expected, it worked.

So yes for NAT64 you need DNS64, but if you have a CLAT in the CPE or in the hosts, even if you don’t use DNS64, everything works fine, so DNSSEC is not broken.

The extra overhead of not doing DNS64, is that all the IPv4 traffic is translated twice (at the CLAT – stateless NAT46 and at the statefull NAT64) vs translating only the IPv4 traffic that uses literals (when you use DNS64).

With NAT64 + DNS64 and 464XLAT (CLAT)
1) IPv6 app <-> IPv6 server (no translation)
2) IPv4/IPv6 app (DNS64) <-> IPv4 server (NAT64 translation) ----> breaks DNSSEC
3) IPv4 app (NAT46 - CLAT) <-> IPv4 server (NAT64 translation)

Without the DNS64
1) IPv6 app <-> IPv6 server (no translation)
2) IPv4/IPv6 app (NAT46 - CLAT) <-> IPv4 server (NAT64 translation)
3) IPv4 app (NAT46 - CLAT) <-> IPv4 server (NAT64 translation)

Already working in a new ID with operational recommendations about this, which can be used in the IETF network as well.

Regards,
Jordi

-----Mensaje original-----
De: ietf <[email-masked]> en nombre de <[email-masked]>
Responder a: <[email-masked]>
Fecha: jueves, 3 de agosto de 2017, 7:45
Para: Christian Huitema <[email-masked]>, "[email-masked]" <[email-masked]>
Asunto: RE: Incremental Deployment of CLAT on the router for IETF Meetings

    Christian, 

    

    Cheers,
    Med

---

From: John Curran <[email-masked]>
Date: Mon, 14 Aug 2017 09:09:42 -0600

On 31 Jul 2017, at 8:10 PM, Randy Bush <[email-masked]> wrote:
> ...
> in our meager experience, pure ipv6 with no hack to get to the ipv4
> internet is not viable from the user perspective, period.  it won't be
> for many years.  yes, this is a tragic failure; and we know where the
> root causes lie.
> 
> nat64/dns64 is useful in constrained circumstances.  the ietf meeting
> network is not one of them; as there is far too wide a variety of users,
> some with laptops they can't even control due to IT departments, many
> use vpns, applications are still incompatible, ...  this is yet another
> tragedy.
> 
> the biggest obstacle to improvement on both these fronts is the denial
> that there are serious problems, and hence far too little serious work
> being done to ameliorate them.
> 
> but, no matter how hard we work, there is not going to be a magic day
> when it all just works.  ipv6 is on-the-wire incompatible with ipv4;
> so it is gonna be hacks; and hacks are tecnhnical debt.

Randy -

Agreed on all of the above – it doesn’t appear that forced usage of IPv6+nat64 
is really compatible with an IETF network "where people can get their work done 
with absolutely minimal speedbumps”

However, the draft proposing same notes that more IPv6/nat64 usage at IETF may 
very well help to identify applications, services, or use cases that are not entirely 
compatible with that setup, and that seems worthwhile - particularly if the lessons
learned are published in a I-D afterwards.

To that end, would it be possible for those behind the "IPv6-only Wi-Fi for IETF”
draft to partner with the NOC at the upcoming meeting to help debug issues that 
are reported on “ietf-nat64* and publish the results?  The IETF does have a wide
variety of users, which is really helpful in finding edge cases with protocols that
might have issues and otherwise go undiscovered.  If it were may clear (e.g. during
the opening) that there is a goal to put the “ietf-nat64” network through its paces
and that there would be a post-mortem I-D as a result, I suspect quite a few folks
would at least give that setup a try for a while, with the goal of finding and reporting
breakage. 

/John

---

From: Lee Howard <[email-masked]>
Date: Wed, 16 Aug 2017 11:01:58 -0400

>would at least give that setup a try for a while, with the goal of

As promised, I have proposed an "IPv4-IPv6 Transition Technology Interop”
for the IETF100 Hackathon:
Description at: 
https://www.ietf.org/registration/MeetingWiki/wiki/100hackathon
Discussion/planning list:
http://lists.retevia.net/listinfo.cgi/v6-interop-retevia.net
Hackathon registration and mailing list at
https://www.ietf.org/hackathon/100-hackathon.html

I have two versions of NAT64 planned (A10, VPP). I would like to compare
to at least 464xlat (probably with CLAT on gateway, not device) to address
some of the comments in the thread. I’d also like to compare other
transition technologies, such as DS-Lite and MAP-T/MAP-E, though these are
probably more interesting to the rest of the Internet than to the narrow
question of what the IETF should do. All of that, of course, is subject to
people wanting to do it, and proper planning ahead of time.

Lee