Subject: [v6ops] I-D Action: draft-ietf-v6ops-rfc6555bis-01.txt

From: [email-masked]
Date: Mon, 05 Jun 2017 16:38:10 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations of the IETF.

        Title           : Happy Eyeballs Version 2: Better Connectivity Using Concurrency
        Authors         : David Schinazi
                          Tommy Pauly
	Filename        : draft-ietf-v6ops-rfc6555bis-01.txt
	Pages           : 13
	Date            : 2017-06-05

Abstract:
   Many communication protocols operated over the modern Internet use
   host names.  These often resolve to multiple IP addresses, each of
   which may have different performance and connectivity
   characteristics.  Since specific addresses or address families (IPv4
   or IPv6) may be blocked, broken, or sub-optimal on a network, clients
   that attempt multiple connections in parallel have a higher chance of
   establishing a connection sooner.  This document specifies
   requirements for algorithms that reduce this user-visible delay and
   provides an example algorithm.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-01
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc6555bis-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-rfc6555bis-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: David Schinazi <[email-masked]>
Date: Mon, 05 Jun 2017 17:10:55 -0700

Hi v6ops,

We have updated draft-ietf-v6ops-rfc6555bis to version 01.
https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-01 <https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-01>

This version incorporates feedback we received on the previous version,
and adds a new section on "Supporting IPv6-only Networks with NAT64 and DNS64"
as these technologies require changes in the Happy Eyeballs stack
on devices that do not support 464XLAT.

Please let us know what you think!

Thanks,
David Schinazi

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 18 Jun 2017 12:57:35 +0200

Hi David,

Very good job! Some comments.

Implementations MUST NOT wait for both families of answers to return
   before attempting connection establishment.  If one query fails to
   return, or takes significantly longer to return, waiting for the
   second address family can significantly delay the connection
   establishment of the first one.  Therefore, the client MUST treat DNS
   resolution as asynchronous.  Note that if the platform does not offer
   an asynchronous DNS API, this behavior can be simulated by making two
   separate synchronous queries on different threads, one per address
   family.  If the AAAA query returns first, the first IPv6 connection
   attempt MUST be immediately started.  If the A query returns first,
   the client SHOULD wait for a short time for the AAAA response.  This
   delay will be referred to as the "Resolution Delay".  The RECOMMENDED
   value for the Resolution Delay is 50 milliseconds.

[Jordi] I’m not sure to fully understand this text, as somehow seems to me contradictory. “waiting for the second address family can significantly delay the connection”, but then you mention 50 milliseconds as recommended. I think it will be nice to clarify it. Also, I think the Resolution Delay should be a parameter, somehow configurable in the OS or apps. This would also facilitate “deprecating” the use of HE (by increasing the delay to an exaggerated value), without necessarily removing the code neither breaking apps that rely on it, when we decide that IPv6 is widely spread so any IPv6 failures should be noticed by end-users in order to pass the message to the ISP, etc.

(note that this is not
   referring to the sending of AAAA or A queries, but rather the address
   of the DNS server itself)

[Jordi] To make it clear, maybe you want to say something such as “… but rather the protocol used for the DNS transport”

This delay is referred
   to as the "Connection Attempt Delay".  One recommended value for this
   delay is 250 milliseconds.

[Jordi] Similar comments about the “Connection Attempt Delay” as earlier: should be a parameter, somehow configurable in the OS or apps. This would also facilitate “deprecating” the use of HE (by increasing the delay to an exaggerated value), without necessarily removing the code neither breaking apps that rely on it, when we decide that IPv6 is widely spread so any IPv6 failures should be noticed by end-users in order to pass the message to the ISP, etc.

464XLAT has the advantage of
   not requiring changes to user space software, however it requires
   per-packet translation and does not encourage client application …

[Jordi] I think this text will make it more accurate:
“464XLAT has the advantage of
   not requiring changes to user space software, however it requires
   per-packet translation in case the application is using IPv4 literals (or similar situations as older socket APIs) and does not encourage client application …

[Jordi] One question here. Should section 7.1 also consider not just literals but old socket APIs?

7.2 Host Names with Broken AAAA Records

[Jordi] I think you could add in this section (or a new section), the case for broken PMTUD. We have today many situations were on purpose or as a consequence of bad implementation of load-balancing, ECMP, etc. You can try it with any web site from 1&1 (for example diskmakerx.com) … just force a reduction on your MTU I you will find that the website is not only non-accessible with IPv6, but also doesn’t work with IPv4, because actual HE implementations aren’t able to detect this problem. I think it will be possible and of course, it will mean removing or having a different text for “9.1.  Path Maximum Transmission Unit Discovery”. I agree that because the nature of HE, active only at the initial stage, we need to somehow extend the HE algorithm to test that, but I think this is the perfect opportunity to make it, because HE is successfully implemented everywhere, so I guess it will be successfully updated. Making it a “different” RFC/protocol, may not have the same impact.

[Jordi] Of course, I think is a major ISP/date center issue, but they aren’t resolving it (tried for two years in this specific case), but there are many others, worldwide, and if we believe HE is the right solution for “ISPs not doing correctly their job”, then we should also support this “failure”. Again, using parameters, to make sure that when IPv6 is more globally spread we can “deprecate” HE and make sure to pass the ball again to those “bad guys in the sense that they don’t do a good job, or don’t make sure that they test correctly their deployments from the perspective of all kind of users”.

8.  Summary of Configurable Values

[Jordi] Looking at this section, you’re saying somehow what I was expressing earlier, so maybe we can make it clearer and is the right place to include a must to have all those parameters as OS configurable ones (by apps, users, network management, etc.).

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de David Schinazi <[email-masked]>
Responder a: <[email-masked]>
Fecha: martes, 6 de junio de 2017, 2:10
Para: IPv6 Ops WG <[email-masked]>
Asunto: [v6ops] Updated draft-ietf-v6ops-rfc6555bis to version 01

    Hi v6ops,

    
    Thanks,
    David Schinazi

    
    
    Abstract:

    

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

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

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

---

From: David Schinazi <[email-masked]>
Date: Tue, 27 Jun 2017 19:43:52 -0700

Hi Jordi,

Thanks for the review! I applied your clarifications to our working copy.

I don't think the document needs to mandate making constants configurable. Modern operating systems receive periodic software updates that can change the values as we work our way towards deprecating Happy Eyeballs. Average smartphone users shouldn't be bothered with this (if you can't configure it you can't misconfigure it).

As we discussed in Chicago, end users should never be made aware of IPv6 network failures as they are not their burden or responsibility to fix. Network operators shouldn't expect their users to be the first ones to notice something's broken. In effect HE will be deprecated when ISPs stop routing IPv4.

Regarding PMTUD, I'm not sure what you're suggesting. HE doesn't currently help with the issue so we marked it out of scope. Are you suggesting a remedy?

Regarding section 7.1, old socket APIs are out of scope as HE is implemented above or alongside sockets. Applications using sockets directly will not get any of these benefits.

Thanks,
David Schinazi

> On Jun 18, 2017, at 03:57, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 
> Hi David,
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 28 Jun 2017 10:18:26 +0200

Hi David,

Below in-line.

-----Mensaje original-----
De: <[email-masked]> en nombre de David Schinazi <[email-masked]>
Responder a: <[email-masked]>
Fecha: miércoles, 28 de junio de 2017, 4:43
Para: <[email-masked]>
CC: IPv6 Ops WG <[email-masked]>
Asunto: Re: [v6ops] Updated draft-ietf-v6ops-rfc6555bis to version 01

    Hi Jordi,

[Jordi] I understand that, however, having parameter in the OS, it means other apps can change that if they need it, even before there is an OS update. There are many users that don’t update the OS, so this is not a good way to ensure a correct future behaviour. Remember recent wannacry, etc., because outdates OS?   

[Jordi] Yes, and not. This is the intend of HE, but if HE only sort outs part of the possible issues, then one way or the other, the user notice it … so this is related with the suggestion for PMTUD failures to be also sorted out by HE …

[Jordi]  Exactly, what I’m suggesting is to improve a bit more HE and be able to verify the PMTUD filtering, so if IPv6 is faster than IPv4, but then PMTUD is filtered, then HE can also “take” the decision to use IPv4. This way we got what you wanted: User not aware of IPv6 failures! I don’t get then the “warning” to the ISP, but we can find a different way for that problem of course …

[Jordi] I understand that, and I’m somehow ignorant about how OS do this internally, so just wondering if we can take also the opportunity to also allow them to use HE.

[Jordi] Final comment. Do you think we can further extend HE in order to provide a way to warn the ISP that HE is forcing IPv4, because IPv6 performance is low? I think we can find several ways to do that, may be a common dns name such as he-fail.isp.com or something similar, that IF the ISP want to implement, gets info about those failures, but the ISP is free to implement it or not. This is useful for those ISPs that really do a good job monitoring their networks, of course, but I think is a perfect opportunity from HE instead of something different.

    Thanks,
    David Schinazi

    
    Hi David,

    
    
    (note that this is not

    This delay is referred

    

    
    [Jordi] I think you could add in this section (or a new section), the case for broken PMTUD. We have today many situations were on purpose or as a consequence of bad implementation of load-balancing, ECMP, etc. You can try it with any web site from 1&1 (for example diskmakerx.com <http://diskmakerx.com>) … just force a reduction on your MTU I you will find that the website is not only non-accessible with IPv6, but also doesn’t work with IPv4, because actual HE implementations aren’t able to detect this problem. I think it will be possible and of course, it will mean removing or having a different text for “9.1.  Path Maximum Transmission Unit Discovery”. I agree that because the nature of HE, active only at the initial stage, we need to somehow extend the HE algorithm to test that, but I think this is the perfect opportunity to make it, because HE is successfully implemented everywhere, so I guess it will be successfully updated. Making it a “different” RFC/protocol, may not have the same impact.

    

    Regards,
    Jordi

    -----Mensaje original-----
    De: v6ops <[email-masked]> en nombre de David Schinazi <[email-masked]>
    Responder a: <[email-masked]>
    Fecha: martes, 6 de junio de 2017, 2:10
    Para: IPv6 Ops WG <[email-masked]>
    Asunto: [v6ops] Updated draft-ietf-v6ops-rfc6555bis to version 01
    
        Hi v6ops,

    
        Thanks,
        David Schinazi

    
    
        Abstract:

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 28 Jun 2017 15:33:21 +0000 (UTC)

Hi David,
Thanks for adding the Supporting IPv6-only Networks with NAT64 and DNS64 section, I find it useful. However I don't think the below sentence from this section is accurate. I can't think of any changes that are needed on a client device to run NAT64/DNS64. 
While many IPv6 transition protocols have been standardized and   deployed, most are transparent to client devices.  The combined use   of NAT64 [RFC6146] and DNS64 [RFC6147] is a popular solution that is   being deployed and requires changes in client devices.
Thanks, Stephan

---

From: David Schinazi <[email-masked]>
Date: Wed, 28 Jun 2017 08:37:28 -0700

Hi Stephan,

Have you read the rest of that section that details the changes required on client devices?

Thanks,
David Schinazi

> On Jun 28, 2017, at 08:33, "[email-masked]" <[email-masked]> wrote:
> 
> Hi David,
> 
> While many IPv6 transition protocols have been standardized and
>    deployed, most are transparent to client devices.  The combined use
>    of NAT64 [RFC6146] and DNS64 [RFC6147] is a popular solution that is
>    being deployed and requires changes in client devices.
> 
> Thanks, Stephan
> 
>

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 28 Jun 2017 15:54:05 +0000 (UTC)

Hi David,
Yes I have. 464XLAT or anything else is not required to be able to run DNS64/NAT64. You can run DNS64/NAT64 in combination with Dual Stack if you want to. 
/S

      From: David Schinazi <[email-masked]>
 To: "[email-masked]" <[email-masked]> 
Cc: IPv6 Ops WG <[email-masked]>
 Sent: Wednesday, June 28, 2017 8:37 AM
 Subject: Re: Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01
   
Hi Stephan,

Thanks,
David Schinazi

Hi David,

---

From: David Schinazi <[email-masked]>
Date: Wed, 28 Jun 2017 14:56:47 -0700

> On Jun 28, 2017, at 01:18, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 

[DS] I don't believe the benefit of increasing HE timers outweighs the risk of misconfiguration.
The section is titled "Summary of Configurable Values" which means OS implementers can choose to make these configurable. Some implementers will not.

> [Jordi]  Exactly, what I’m suggesting is to improve a bit more HE and be able to verify the PMTUD filtering, so if IPv6 is faster than IPv4, but then PMTUD is filtered, then HE can also “take” the…

[DS] Solving PMTUD issues is currently done inside the TCP stack not HE, I'm not certain of the value of adding complexity to HE for this.

> [Jordi] I understand that, and I’m somehow ignorant about how OS do this internally, so just wondering if we can take also the opportunity to also allow them to use HE.

[DS] That isn't possible with current architectures, but either way we're moving away from sockets so I don't think there's much value in solving this issue:
https://tools.ietf.org/html/draft-trammell-taps-post-sockets <https://tools.ietf.org/html/draft-trammell-taps-post-sockets>

> [Jordi] Final comment. Do you think we can further extend HE in order to provide a way to warn the ISP that HE is forcing IPv4, because IPv6 performance is low? I think we can find several ways to…

[DS] That sounds reasonable to me, I think it deserves its own draft though (and will require a serious discussion about user privacy implications).

Thanks,
David Schinazi

---

From: David Schinazi <[email-masked]>
Date: Wed, 28 Jun 2017 15:00:13 -0700

This section is titled "Supporting IPv6-only Networks with NAT64 and DNS64", dual-stack is out of scope of this section.

Am I missing something?

Thanks,
David Schinazi

> On Jun 28, 2017, at 08:54, [email-masked] wrote:
> 
> Hi David,
> 
> On Jun 28, 2017, at 08:33, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hi David,
>>

---

From: Mark Andrews <[email-masked]>
Date: Thu, 29 Jun 2017 08:00:25 +1000

In message <[email-masked]>, "stephan.lagerholm@
yahoo.com" writes:
> Hi David,
> Thanks for adding the Supporting IPv6-only Networks with NAT64 and DNS64
> section, I find it useful. However I don't think the below sentence from
> this section is accurate. I can't think of any changes that are needed on
> a client device to run NAT64/DNS64. 

Well you obviously don't have any devices doing DNSSEC validation.
DNS64 breaks DNSSEC as it changes the DNS responses from NOERROR
NODATA to NOERROR DATA by synthesizing a AAAA RRset.  This from the
client's perspective is not different than forging a fake AAAA RRset
that is trying to hijack the traffic stream.

Now very few, if any, mobile phones perform DNSSEC but there are
laptop and desktop machines that do.

> deployed, most are transparent to client devices.  The combined use   of
> NAT64 [RFC6146] and DNS64 [RFC6147] is a popular solution that is   being
> deployed and requires changes in client devices.
> Thanks, Stephan

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

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 28 Jun 2017 22:59:03 +0000 (UTC)

Fair enough, the Dual stack example is not applicable in this section. I'm hung up that the draft says that it requires changes on in client devices because it contradicts RFC 6174 section 2 that says that current IPv6 nodes can use this mechanism without requiring any modifications. 

The first option is to locate the DNS64 function in authoritative
   servers for a zone.  In this case, the authoritative server provides
   synthetic AAAA RRs for an IPv4-only host in its zone.  This is one
   type of DNS64 server.

   Another option is to locate the DNS64 function in recursive name
   servers serving end hosts.  In this case, when an IPv6-only host
   queries the name server for AAAA RRs for an IPv4-only host, the name
   server can perform the synthesis of AAAA RRs and pass them back to
   the IPv6-only initiator.  The main advantage of this mode is that
   current IPv6 nodes can use this mechanism without requiring any
   modification.

 Sent: Wednesday, June 28, 2017 3:00 PM
   
Thanks,David Schinazi

  
Hi Stephan,

Thanks,
David Schinazi

Hi David,

---

From: David Schinazi <[email-masked]>
Date: Wed, 28 Jun 2017 16:10:46 -0700

Absolutely, the text in RFC 6147 did not consider the scenarios described here.
I'll mark this document as updating RFC 6147 to reflect that.

David Schinazi

> On Jun 28, 2017, at 15:59, [email-masked] wrote:
> 
>> On Jun 28, 2017, at 08:54, [email-masked] <mailto:[email-masked]> wrote:
>> 
>> Hi David,
>> 
>> From: David Schinazi <[email-masked] <mailto:[email-masked]>>
>> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>> 
>> Cc: IPv6 Ops WG <[email-masked] <mailto:[email-masked]>>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 29 Jun 2017 02:37:42 +0200 (CEST)

On Wed, 28 Jun 2017, [email-masked] wrote:

> Fair enough, the Dual stack example is not applicable in this 
> section. I'm hung up that the draft says that it requires changes on in 
> client devices because it contradicts RFC 6174 section 2 that says that 
> modifications. 

But that doesn't mean applications running on those IPv6 nodes can access 
IPv4 literals. If the node also implements a CLAT, then it can.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 29 Jun 2017 03:01:42 +0000 (UTC)

Hi Mark,
>From: Mark Andrews <[email-masked]>>> In message <[email-masked]>, "[email-masked]" writes:
>> Hi David,

This case and the remedy is already covered in RFC 6147 section 3. I don't think it makes sense to bring it up in this draft. 

/S

|  | Virus-free. www.avg.com  |

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 29 Jun 2017 03:21:27 +0000 (UTC)

Hi Mikael,

>        Mikael Abrahamsson <[email-masked]>
>>

This section of the rfc6555bis draft is addressing "platforms that do not support 464XLAT" so no CLAT here. 
But we are on the same page, I'm happy that the authors are addressing the IPv6 only use case and are extending HE to support that case too. 

/Stephan

---

From: Mark Andrews <[email-masked]>
Date: Thu, 29 Jun 2017 14:14:33 +1000

> On 29 Jun 2017, at 1:01 pm, [email-masked] wrote:
> 
> Hi Mark,
> 
> >From: Mark Andrews <[email-masked]>
> >> In message <[email-masked]>, "[email-masked]" writes:
> >> Hi David,

RFC 6147 states that end devices need to be upgraded.  Yes
this is in contradiction to itself where it states that they don’t need
to be upgraded.

Section 5.5.

       The disadvantage to this approach is that an end point that is
       translation-oblivious but security-aware and validating will not
       be able to use the DNS64 functionality.  In this case, the end
       point will not have the desired benefit of NAT64.  In effect,
       this strategy means that any end point that wishes to do
       validation in a NAT64 context must be upgraded to be
       translation-aware as well.

Then you have 5.5.3, turn a DNSSEC MUST NOT into a MAY
and in doing so completely defeating the purpose of the “MUST NOT”
on CD=1 which is to get answers which are incorrectly being rejected
by the upstream validating resolver.

       "then vDNS64 MAY perform validation,”

Then you have changes to the purpose of CD which don’t work
with TTL=0 answers.

The whole IETF seems to think that DNS64/NAT64 works well.  It
doesn’t when you need to use the protections that DNSSEC
provides.  It works ok if everything else is correctly configured and
there are no active attacks on the recursive DNS servers happening.

> 	Virus-free. www.avg.com

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 29 Jun 2017 04:52:47 +0000 (UTC)

Hi Mark,
>        Mark Andrews <[email-masked]> 
>

I agree that it does not work well if you validate on the stub resolver side. I can imagine that you could do an RFC7050 query within your validator, strip the pref64 and then validate the A record. I still think it should be outside the scope of this draft to tackle DNSSEC related issues when using DNS64. It is not going to add any clarity to Happy Eyeballs to have text around DNSSEC related issues that remains unchanged with or without this draft being implemented. I'm happy to work on an rfc6174bis with you. 

/Stephan

---

From: Erik Kline <[email-masked]>
Date: Thu, 29 Jun 2017 13:58:07 +0900

> there are no active attacks on the recursive DNS servers happening.

When the *end client* needs to do DNSSec.  If the recursive servers
unconditionally do DNSSec on the clients' behalf for NAT64/DNS64 networks,
that seems like a reasonable operational SHOULD/MUST we can mention.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 29 Jun 2017 15:17:41 +1000

> that seems like a reasonable operational SHOULD/MUST we can mention.

The real problem is the choice to promote DNS64/NAT64.  Just because
it works "well enough" in the cellular envionment *where there is
little to no DNSSEC being used (read as epsilon)*, that is not a
reason to promote it as a *general* solution for IPv6-only networks.
Doing that will come back to bite us in the future.

Mark

---

From: Fred Baker <[email-masked]>
Date: Thu, 29 Jun 2017 07:30:43 +0200

> Doing that will come back to bite us in the future.

I'm not sure I disagree, in the sense that the preferred approach would be to move the application to IPv6. That said, isn't the point that it hasn't yet been moved but the network is? The only option other than "translate" is "don't turn off IPv4". I think that will be a common solution. But when the network is turning off IPv4 and an IPv6-capable option isn't available for an application, I think they're not going to ask your opinion. They're going to do something that works for them.

---

From: <[email-masked]>
Date: Thu, 29 Jun 2017 05:43:03 +0000

Hi David,

I don't think your document is updating RFC6147.

Cheers,
Med

De : v6ops [mailto:[email-masked]] De la part de David Schinazi
Envoyé : jeudi 29 juin 2017 01:11
À : [email-masked]
Cc : IPv6 Ops WG
Objet : Re: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01

David Schinazi

On Jun 28, 2017, at 15:59, [email-masked]<mailto:[email-masked]> wrote:

   type of DNS64 server.

   modification.

________________________________
From: David Schinazi <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: IPv6 Ops WG <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, June 28, 2017 3:00 PM
Subject: Re: Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01

Am I missing something?

Thanks,
David Schinazi

On Jun 28, 2017, at 08:54, [email-masked]<mailto:[email-masked]> wrote:

Hi David,

/S

________________________________
From: David Schinazi <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: IPv6 Ops WG <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, June 28, 2017 8:37 AM
Subject: Re: Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01

Hi Stephan,

Thanks,
David Schinazi

On Jun 28, 2017, at 08:33, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:
Hi David,

Thanks, Stephan

---

From: Mark Andrews <[email-masked]>
Date: Thu, 29 Jun 2017 15:52:48 +1000

> On 29 Jun 2017, at 3:30 pm, Fred Baker <[email-masked]> wrote:
> 
> 

There are other mechanisms to reach IPv4 machines from IPv6-only
networks.  DS-Lite in host mode is one such mechanism.  That works
with IPv4 literals and it works with DNSSEC.  It does require that the
host listen for the DHCPv6 option and establish a tunnel based on the
data in that option.  The host can preference IPv6 over IPv4 when sorting
the addresses to try.  It provides a fallback when the AAAA records are
broken or the service is only available over IPv4.

DS-Lite host mode shouldn’t have TCP PMTU issues as the MSS size
advertised should be accounting for reduced size.  For NAT64 you need
to do mss fixup hacks to avoid this.  NAT64 and DS-Lite have the same
PMTU limitations with UDP (just the effective MTU is a touch higher with
NAT64).

Mark

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 29 Jun 2017 06:19:47 +0000

Perhaps, have section 7 for IPv6-only network with 2 sub-sections -

7.1 pointing out transition technologies such as 464XLAT based on DNS64/NAT64 that breaks DNSSEC for v4 destinations.

7.2 pointing out that MAP-T/E not breaking DNSSEC since there is no DNS64 involved.

I still think it should be outside the scope of this draft to tackle DNSSEC related issues when using DNS64.

Agreed.

Cheers,
Rajiv Asati
Distinguished Engineer, Cisco Services

On Jun 28, 2017, at 9:53 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Mark,
>        Mark Andrews <[email-masked]<mailto:[email-masked]>>
>
>> On 29 Jun 2017, at 1:01 pm, [email-masked]<mailto:[email-masked]> wrote:
>>
>> Hi Mark,
>>
>> >From: Mark Andrews <[email-masked]<mailto:[email-masked]>>
>> >> In message <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" writes:
>> >> Hi David,
>this is in contradiction to itself where it states that they don't need
>to be upgraded.
>
>Section 5.5.
>
>and in doing so completely defeating the purpose of the "MUST NOT"
>      "then vDNS64 MAY perform validation,"
>
>Then you have changes to the purpose of CD which don't work
>with TTL=0 answers.
>
>doesn't when you need to use the protections that DNSSEC

/Stephan
_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: <[email-masked]>
Date: Thu, 29 Jun 2017 07:03:21 +0000

Hi Rajiv,

Please see inline.

Cheers,
Med

De : v6ops [mailto:[email-masked]] De la part de Rajiv Asati (rajiva)
Envoyé : jeudi 29 juin 2017 08:20
À : [email-masked]
Cc : IPv6 Ops WG
Objet : Re: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01

7.2 pointing out that MAP-T/E not breaking DNSSEC since there is no DNS64 involved.
[Med] This is also true for other solutions, including NAT64. See, for example:

·         https://tools.ietf.org/html/rfc6147#section-5.5

·         https://tools.ietf.org/html/rfc7225#section-3.1

Agreed.

Cheers,
Rajiv Asati

/Stephan

---

From: Fred Baker <[email-masked]>
Date: Thu, 29 Jun 2017 09:05:53 +0200

> On Jun 29, 2017, at 7:52 AM, Mark Andrews <[email-masked]> wrote:
> 
> networks.  DS-Lite in host mode is one such mechanism.

True, and if the host implements the protocol that probably works. If it is an unmodified host...

---

From: Fred Baker <[email-masked]>
Date: Thu, 29 Jun 2017 09:24:07 +0200

> networks.  DS-Lite in host mode is one such mechanism.

Thinking through my comments a little further. I'm not portraying the issue well. Let's start out with a picture.

I have three hosts that need to talk with each other. They are running the same application or compatible applications, but two (Hosts A and B) are on an IPv6-only network and the third (Host C) is on an IPv4-only network.
                                                 +------+
                                                 |Host A|
                                                 +------+
                                                 /
             ,-----.                      ,---. /
 +------+   /       \   +------------+   /     \
 |Host C+--(   IPv4  )--+Interconnect+--( IPv6  )
 +------+   \       /   +------------+   \     /
             `-----'                      `---'\
                                                \+------+
                                                 |Host B|
                                                 +------+

So, contrary to what I said a few moments ago, the application is IPv6-capable. My error.

What you propose is that Host A somehow know that Host B is IPv6-capable and that Host C is not, and choose an alternative and not-widely-deployed mechanism such as DS-Lite in Host Mode for access to Host C. This requires the administrator of the network Host A is in to give it relevant software and whatever is required to communicate that distinction.

What a translation model proposes is that Host A sees both Host B and Host C as IPv6-capable and talk with them the same way. Host C's IPv6 address is in a certain prefix and contains an embedded IPv4 address. Host A doesn't necessarily realize that - it sees a 128 bit address and uses it. The network changes the underlying Internet Protocol to make that work.

Is that a perfect solution? NAT is never a perfect solution, and I don't think anyone here is saying anything different. But operationally, the administrator doesn't have to change Host A or do anything magical to make this work. It has issues, specifically with DNSSEC as you point out. One could argue that the Interconnect is a perfect MITM, and one would argue correctly. But using a translator allows most of what needs to happen without saddling the administrator with a gargantuan task. If he has a huge task, he is unlikely to do it at all. If he can do something relatively simple, he can take baby steps.

Recall that Host C is presumably not under his/her control, but he presumably has business reasons to enable access between the hosts.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 29 Jun 2017 17:51:05 +1000

> True, and if the host implements the protocol that probably works. If it

There is no clean solution that works, in general, for unmodified hosts
connected IPv6-only network.  They all require something to be modified.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 29 Jun 2017 09:52:14 +0200

[Jordi-2] Do you think it makes sense to let the implementors to not make them configurable? Because if that’s the case then a strong recommendation to make it configurable in section 8, should work ;-)

    

    

[Jordi-2] Here is the point. I now increase a bit the HE complexity, but we are taking a big opportunity of a successfully widely implemented mechanisms to do something very good with an update. If instead of that we choose to write a *new* mechanism specific for detecting the PMTUD problem, it will take much longer to become widely implemented, and I think we are in the IETF to solve the problems in a way that is more convenient and better for the community, right?

    

    [DS] That isn't possible with current architectures, but either way we're moving away from sockets so I don't think there's much value in solving this issue:
    https://tools.ietf.org/html/draft-trammell-taps-post-sockets
    
[Jordi-2] got it, thanks!
    
    [Jordi] Final comment. Do you think we can further extend HE in order to provide a way to warn the ISP that HE is forcing IPv4, because IPv6 performance is low? I think we can find several ways to do that, may be a common dns name such as he-fail.isp.com <http://he-fail.isp.com> or something similar, that IF the ISP want to implement, gets info about those failures, but the ISP is free to implement it or not. This is useful for those ISPs that really do a good job monitoring their networks, of course, but I think is a perfect opportunity from HE instead of something different.

[Jordi-2] Same argument as above for the PMTUD. I think is feasible to make it in the same document and take the opportunity of the success. I understand that it may mean that the move to last call may take a couple of additional cycles. It is not my intent to delay this at all, but instead, to make whatever is better for the community. A couple of months of delay is worth instead of waiting years for an alternative protocol to be implemented widely. I’m sure you understand my point. This is my suggestion. I guess you will be in Prague. Let’s work (probably other people is interested in that) in a couple of alternatives about how to do this from now to the meeting. Then we can met face to face on Sunday in Prague and we can advance it as much as possible, and we could ask in the v6ops session a poll about this with already “something” in draft (may be presenting) a couple of choices. I’m happy to draft something in the next couple of days. I understand what you mean about the privacy implications, however: 1) The ISPs are already mandated by law to log the data of the customers 2) We don’t need to send the ISP the address of the host, the WAN address is enough probably (just a quick idea).
    
    Thanks,
    David Schinazi