Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Jul 2017 07:24:24 +0200

In my opinion such kind of experiment should be only done once we approve the document as RFC, note before, so by the next IETF meeting (hopefully).

We like it or not, this is not a valid option, unless we make sure that if some participants have troubles, the alternative SSIDs have other 2.4 and 5 GHz radios available. Is that the case?

The unfortunate reason this doesn’t work is that, still there are MANY apps that use literals or old APIs, that don’t work with NAT64.

As I explained before, if the goal is to detect and test them, this can be done by using a “CLAT” network (464XLAT) in the default SSID, and then having an automatic logging of what apps/destination IPs), are using the CLAT.

Those using IPv6 are fine, those using just the PLAT (NAT64+DNS64) are also fine.

The result is the same as you’re proposing but non-intrusive and with the advantage of an automated logging of the failures.

The way you’re proposing, will mean that many folks may switch to alternative SSID, or simply don't report those failures, so at the end you don’t have any results of how much is not working, etc.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de "Brzozowski, John" <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 17 de julio de 2017, 6:23
Para: "[email-masked]" <[email-masked]>
CC: Jim Martin <[email-masked]>, Alissa Cooper <[email-masked]>, Russ Housley <[email-masked]>, Randy Bush <[email-masked]>, Suresh Krishnan <[email-masked]>
Asunto: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    Folks,
    
    Apologies in advance for the gratuitous cross posting (v6ops, ietf, ipv6, sunset4, softwires).  I hope, to you all, this is worth the added email.
    
    The draft below was written to provide the necessary documentation to enable the IETF (the NOC, participants, etc.) to migrate to an IPv6 only primary network connection (Wi-Fi and wired) that utilizes NAT64+DNS64 to access IPv4 only content.  The request for IETF 99 has been to have the primary “ietf” SSID adhere to what is documented in the I-D below.  I trust the motivation is understood.  This means that the main “ietf” SSID would be switched to be IPv6 only with NAT64+DNS64 (at layer 3) per the I-D below.  Given the that IETF99 is upon us, this may or may not be entirely possible.
    
    At this stage, the infrastructure preparations for IETF 99 should be in place to ensure that the IETF has the necessary hardware for redundancy and performance.
    
    So, we are all seeking your input.  Given the above, what would all you suggest is tolerable for IETF99 as it pertains to the I-D below?
    
    • IPv6 only per the I-D for the balance of IETF week?
    • IPv6 only per the I-D for one or more days this week?
    • IPv6 only per the I-D for the plenary?
    • IPv6 only per the I-D for the next IETF meeting?
    
    Please send us your feedback.
    
    Regards,
    
    John
    +1-484-962-0060
    
    -----Original Message-----
    From: "[email-masked]" <[email-masked]>
    Date: Saturday, July 1, 2017 at 03:04
    To: Marcus Keane <[email-masked]>, Jen Linkova <[email-masked]>, Lorenzo Colitti <[email-masked]>, John Brzozowski <[email-masked]>, Erik Kline <[email-masked]>, John Brzozowski <[email-masked]>, David Schinazi <[email-masked]>, Stuart Cheshire <[email-masked]>, Jen Linkova <[email-masked]>, Paul Saab <[email-masked]>, David Schinazi <[email-masked]>
    Subject: New Version Notification for draft-jjmb-v6ops-ietf-ipv6-only-incremental-00.txt

        A new version of I-D, draft-jjmb-v6ops-ietf-ipv6-only-incremental-00.txt
        has been successfully submitted by John Jason Brzozowski and posted to the
        IETF repository.
        
        Name:		draft-jjmb-v6ops-ietf-ipv6-only-incremental
        Revision:	00
        Title:		Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
        Document date:	2017-06-30
        Group:		Individual Submission
        Pages:		15
        URL:            https://www.ietf.org/internet-drafts/draft-jjmb-v6ops-ietf-ipv6-only-incremental-00.txt
        Status:         https://datatracker.ietf.org/doc/draft-jjmb-v6ops-ietf-ipv6-only-incremental/
        Htmlized:       https://tools.ietf.org/html/draft-jjmb-v6ops-ietf-ipv6-only-incremental-00
        Htmlized:       https://datatracker.ietf.org/doc/html/draft-jjmb-v6ops-ietf-ipv6-only-incremental-00

        Abstract:
           The purpose of this document is to provide a blueprint and guidance
           for deploying IPv6-only Wi-Fi at IETF meetings.  This document
           outlines infrastructure and operational guidance that operators
           should consider when deploying IPv6-only networks using NAT64 and
           DNS64 to support communication to legacy IPv4-only services.

        
        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.
        
        The IETF Secretariat

    
    _______________________________________________
    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: Ted Lemon <[email-masked]>
Date: Mon, 17 Jul 2017 07:33:30 +0200

Fwiw, I have found and fixed lots of problems as a result of using the
ietf-nat64 network. It is probably still try that some participants would
have trouble on that network, so there should be a legacy network for them.
But the default should be nat64. Dogfooding is really important. If you
have broken apps, feeling a little pain is a great way to motivate
complaining about it to the vendor.

On Jul 17, 2017 7:26 AM, "JORDI PALET MARTINEZ" <[email-masked]>
wrote:

> In my opinion such kind of experiment should be only done once we approve
> the document as RFC, note before, so by the next IETF meeting (hopefully).
>
> We like it or not, this is not a valid option, unless we make sure that if
> some participants have troubles, the alternative SSIDs have other 2.4 and 5
> GHz radios available. Is that the case?
>
> The unfortunate reason this doesn’t work is that, still there are MANY
> apps that use literals or old APIs, that don’t work with NAT64.
>
> As I explained before, if the goal is to detect and test them, this can be
> done by using a “CLAT” network (464XLAT) in the default SSID, and then
> having an automatic logging of what apps/destination IPs), are using the
> CLAT.
>
> The result is the same as you’re proposing but non-intrusive and with the
> advantage of an automated logging of the failures.
>
> The way you’re proposing, will mean that many folks may switch to
> alternative SSID, or simply don't report those failures, so at the end you
> don’t have any results of how much is not working, etc.
>
> Regards,
> Jordi
>
>
> Para: "[email-masked]" <
> [email-masked]>
> CC: Jim Martin <[email-masked]>, Alissa Cooper <[email-masked]>,
> Russ Housley <[email-masked]>, Randy Bush <[email-masked]>, Suresh
> Krishnan <[email-masked]>
>     Apologies in advance for the gratuitous cross posting (v6ops, ietf,
> ipv6, sunset4, softwires).  I hope, to you all, this is worth the added
> email.
>
>     The draft below was written to provide the necessary documentation to
> enable the IETF (the NOC, participants, etc.) to migrate to an IPv6 only
> primary network connection (Wi-Fi and wired) that utilizes NAT64+DNS64 to
> access IPv4 only content.  The request for IETF 99 has been to have the
> primary “ietf” SSID adhere to what is documented in the I-D below.  I trust
> the motivation is understood.  This means that the main “ietf” SSID would
> be switched to be IPv6 only with NAT64+DNS64 (at layer 3) per the I-D
> below.  Given the that IETF99 is upon us, this may or may not be entirely
> possible.
>
>     At this stage, the infrastructure preparations for IETF 99 should be
> in place to ensure that the IETF has the necessary hardware for redundancy
> and performance.
>
>     So, we are all seeking your input.  Given the above, what would all
> you suggest is tolerable for IETF99 as it pertains to the I-D below?
>
>     To: Marcus Keane <[email-masked]>, Jen Linkova <
> [email-masked]>, Lorenzo Colitti <[email-masked]>, John Brzozowski <
> [email-masked]>, Erik Kline <[email-masked]>, John
> Brzozowski <[email-masked]>, David Schinazi <
> [email-masked]>, Stuart Cheshire <[email-masked]>, Jen Linkova <
> [email-masked]>, Paul Saab <[email-masked]>, David Schinazi <
> [email-masked]>
>         URL:            https://www.ietf.org/internet-
> drafts/draft-jjmb-v6ops-ietf-ipv6-only-incremental-00.txt
>         Status:         https://datatracker.ietf.org/
> doc/draft-jjmb-v6ops-ietf-ipv6-only-incremental/
>         Htmlized:       https://tools.ietf.org/html/
> draft-jjmb-v6ops-ietf-ipv6-only-incremental-00
>         Htmlized:       https://datatracker.ietf.org/
> doc/html/draft-jjmb-v6ops-ietf-ipv6-only-incremental-00
>
>
>         Abstract:
> 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: joel jaeggli <[email-masked]>
Date: Mon, 17 Jul 2017 07:41:00 +0200

> We like it or not, this is not a valid option, unless we make sure that if some participants have troubles, the alternative SSIDs have other 2.4 and 5 GHz radios available. Is that the case?

That's not a serious consideration. the RF properties of the ssid are
indepedantly controlled by the access points themselves. All IETF ssids
are provided by the same sets of APs/Radios

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Jul 2017 07:44:07 +0200

What I’m saying is that using CLAT, you also have dogfooding, but no disturbing any participants and allowing then to keep doing the work. Some of us get paid only if we finish our work on time!

I always understood that the IETF network is not for experiments. If we allow this, it means we are changing our policy from now on?

I recall previous occasions where it was clearly said that if an experiment is going to affect other participants, it can’t be done.

As said, do the same with CLAT so participants aren’t affected and at least wait until the document is an RFC.

I’m pro-IPv6, I’m sure nobody doubts that, but work is first, rules as well.

Regards,
Jordi

-----Mensaje original-----
De: Ted Lemon <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 17 de julio de 2017, 7:33
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: Alissa Cooper <[email-masked]>, Suresh Krishnan <[email-masked]>, <[email-masked]>, Jim Martin <[email-masked]>, Randy Bush <[email-masked]>, Russ Housley <[email-masked]>
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    Fwiw, I have found and fixed lots of problems as a result of using the ietf-nat64 network. It is probably still try that some participants would have trouble on that network, so there should be a legacy network for them. But the default should be nat64. Dogfooding is really important. If you have broken apps, feeling a little pain is a great way to motivate complaining about it to the vendor. 
    
    On Jul 17, 2017 7:26 AM, "JORDI PALET MARTINEZ" <[email-masked]> wrote:

    

    

    Regards,
    Jordi

    -----Mensaje original-----
    De: v6ops <[email-masked]> en nombre de "Brzozowski, John" <[email-masked]>
    Responder a: <[email-masked]>
    Fecha: lunes, 17 de julio de 2017, 6:23
    Para: "[email-masked]" <[email-masked]>
    CC: Jim Martin <[email-masked]>, Alissa Cooper <[email-masked]>, Russ Housley <[email-masked]>, Randy Bush <[email-masked]>, Suresh Krishnan <[email-masked]>
    Asunto: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
    
        Folks,

    

    
    
        Regards,
    
        John
        +1-484-962-0060
    
        -----Original Message-----
        From: "[email-masked]" <[email-masked]>
        Date: Saturday, July 1, 2017 at 03:04
        To: Marcus Keane <[email-masked]>, Jen Linkova <[email-masked]>, Lorenzo Colitti <[email-masked]>, John Brzozowski <[email-masked]>, Erik Kline <[email-masked]>, John Brzozowski <[email-masked]>, David Schinazi <[email-masked]>, Stuart Cheshire <[email-masked]>, Jen Linkova <[email-masked]>, Paul Saab <[email-masked]>, David Schinazi <[email-masked]>
        Subject: New Version Notification for draft-jjmb-v6ops-ietf-ipv6-only-incremental-00.txt

            Abstract:

    
            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 <http://tools.ietf.org>.
    
            The IETF Secretariat

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Jul 2017 07:44:07 +0200

Regards,
Jordi

-----Mensaje original-----
De: Ted Lemon <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 17 de julio de 2017, 7:33
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: Alissa Cooper <[email-masked]>, Suresh Krishnan <[email-masked]>, <[email-masked]>, Jim Martin <[email-masked]>, Randy Bush <[email-masked]>, Russ Housley <[email-masked]>
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    

    

    
    
    Regards,
    Jordi

    -----Mensaje original-----
    De: v6ops <[email-masked]> en nombre de "Brzozowski, John" <[email-masked]>
    Responder a: <[email-masked]>
    Fecha: lunes, 17 de julio de 2017, 6:23
    Para: "[email-masked]" <[email-masked]>
    CC: Jim Martin <[email-masked]>, Alissa Cooper <[email-masked]>, Russ Housley <[email-masked]>, Randy Bush <[email-masked]>, Suresh Krishnan <[email-masked]>
    Asunto: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
    
        Folks,

    

    
    
        Regards,
    
        John
        +1-484-962-0060
    
        -----Original Message-----
        From: "[email-masked]" <[email-masked]>
        Date: Saturday, July 1, 2017 at 03:04
        To: Marcus Keane <[email-masked]>, Jen Linkova <[email-masked]>, Lorenzo Colitti <[email-masked]>, John Brzozowski <[email-masked]>, Erik Kline <[email-masked]>, John Brzozowski <[email-masked]>, David Schinazi <[email-masked]>, Stuart Cheshire <[email-masked]>, Jen Linkova <[email-masked]>, Paul Saab <[email-masked]>, David Schinazi <[email-masked]>
        Subject: New Version Notification for draft-jjmb-v6ops-ietf-ipv6-only-incremental-00.txt

            Abstract:

    
    
            The IETF Secretariat

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Jul 2017 07:58:43 +0200

"No disturbing the participants" means we aren't dogfooding.   That's what
dogfooding means: you try to use the dog food.  If it's not nutritious,
then you go back to the cat food, but you start with the dog food.   Even
if you are only dogfooding for ten minutes before you run into a problem
that requires you to switch to the legacy network, that's a win, at least
if you report the problem.

On Mon, Jul 17, 2017 at 7:44 AM, JORDI PALET MARTINEZ <
[email-masked]> wrote:

> What I’m saying is that using CLAT, you also have dogfooding, but no
> disturbing any participants and allowing then to keep doing the work. Some
> of us get paid only if we finish our work on time!
>
> I always understood that the IETF network is not for experiments. If we
> allow this, it means we are changing our policy from now on?
>
> I recall previous occasions where it was clearly said that if an
> experiment is going to affect other participants, it can’t be done.
>
> CC: Alissa Cooper <[email-masked]>, Suresh Krishnan <
> [email-masked]>, <[email-masked]>, Jim Martin <[email-masked]>,
> Randy Bush <[email-masked]>, Russ Housley <[email-masked]>
>     In my opinion such kind of experiment should be only done once we
> approve the document as RFC, note before, so by the next IETF meeting
> (hopefully).
>
>     We like it or not, this is not a valid option, unless we make sure
> that if some participants have troubles, the alternative SSIDs have other
> 2.4 and 5 GHz radios available. Is that the case?
>
>     As I explained before, if the goal is to detect and test them, this
> can be done by using a “CLAT” network (464XLAT) in the default SSID, and
> then having an automatic logging of what apps/destination IPs), are using
> the CLAT.
>
>     The result is the same as you’re proposing but non-intrusive and with
> the advantage of an automated logging of the failures.
>
>         Apologies in advance for the gratuitous cross posting (v6ops,
> ietf, ipv6, sunset4, softwires).  I hope, to you all, this is worth the
> added email.
>
>         The draft below was written to provide the necessary documentation
> to enable the IETF (the NOC, participants, etc.) to migrate to an IPv6 only
>         At this stage, the infrastructure preparations for IETF 99 should
> be in place to ensure that the IETF has the necessary hardware for
> redundancy and performance.
>
>         So, we are all seeking your input.  Given the above, what would
> all you suggest is tolerable for IETF99 as it pertains to the I-D below?
>
>     This electronic message contains information which may be privileged
> or confidential. The information is intended to be for the use of the

---

From: Noah <[email-masked]>
Date: Mon, 17 Jul 2017 09:14:13 +0300

On 17 Jul 2017 8:26 a.m., "JORDI PALET MARTINEZ" <[email-masked]>
wrote:

Hi Jordi

Why not, this would be very interesting considering the times.

Perhaps we can try for 1 or 2 days for experiental purpose as need not to
wait for final RFC and the outcome could also feed the current draft as is.
Who knows.

+1 for below option if possible.

-  IPv6 only per the I-D for one or more days this week?

Cheers
Noah

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Jul 2017 08:27:45 +0200

Not disturbing means allowing them to work transparently, and this is the target of our network. There is no reason to force “breaking” something if the target is to measure something that can be done in another way, right?

As said:
1) If we allow and ID to be experimented in our network (which is against our own rules), then it means that if somebody else tomorrow decides to write down another ID, he has the same right to ask for being experimented at the default SSID.
2) The way I’m suggesting provides even better results for analysis. I agree that is good to understand what apps will fail to survive the NAT64.
3) CLAT is also our own dogfood.

Regards,
Jordi

-----Mensaje original-----
De: Ted Lemon <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 17 de julio de 2017, 7:59
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: IPv6 Ops WG <[email-masked]>, Randy Bush <[email-masked]>, Alissa Cooper <[email-masked]>, Russ Housley <[email-masked]>, Jim Martin <[email-masked]>, Suresh Krishnan <[email-masked]>
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    "No disturbing the participants" means we aren't dogfooding.   That's what dogfooding means: you try to use the dog food.  If it's not nutritious, then you go back to the cat food, but you start with the dog food.   Even if you are only dogfooding for ten minutes before you run into a problem that requires you to switch to the legacy network, that's a win, at least if you report the problem.
    
    On Mon, Jul 17, 2017 at 7:44 AM, JORDI PALET MARTINEZ <[email-masked]> wrote:

    

    
    Regards,
    Jordi

    -----Mensaje original-----
    De: Ted Lemon <[email-masked]>
    Responder a: <[email-masked]>
    Fecha: lunes, 17 de julio de 2017, 7:33
    Para: JORDI PALET MARTINEZ <[email-masked]>
    CC: Alissa Cooper <[email-masked]>, Suresh Krishnan <[email-masked]>, <[email-masked]>, Jim Martin <[email-masked]>, Randy Bush <[email-masked]>, Russ Housley <[email-masked]>
    Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    

    

    
    
        Regards,
        Jordi

        -----Mensaje original-----
        De: v6ops <[email-masked]> en nombre de "Brzozowski, John" <[email-masked]>
        Responder a: <[email-masked]>
        Fecha: lunes, 17 de julio de 2017, 6:23
        Para: "[email-masked]" <[email-masked]>
        CC: Jim Martin <[email-masked]>, Alissa Cooper <[email-masked]>, Russ Housley <[email-masked]>, Randy Bush <[email-masked]>, Suresh Krishnan <[email-masked]>
        Asunto: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
    
            Folks,

    

    
    
            Regards,
    
            John
            +1-484-962-0060
    
            -----Original Message-----

                Abstract:

    

                until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org> <http://tools.ietf.org>.
    
                The IETF Secretariat

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Jul 2017 08:32:06 +0200

NAT64 has been tested already in many networks, it just works but ONLY if your app isn’t using literals or old libraries, etc. So the only “new” thing we can learn from this experiment is what apps break because that. The way I’m suggesting (464XLAT) has been also tested in many networks, and actually is globally deployed in almost every cellular network that provides IPv6. The results we can get using this instead of only NAT64, is that those apps that break will be automatically logged.

If we just do NAT64, do you expect the users that have a break to “report” manually what is broken for them. May be 10% will do. With CLAT, we collect automatically 100%.

Which one do you think is more advantageous?

Also, note that the IETF network has always been described as a non-place for experiments.

Regards,
Jordi

-----Mensaje original-----
De: Noah <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 17 de julio de 2017, 8:14
Para: <[email-masked]>
CC: Alissa Cooper <[email-masked]>, Suresh Krishnan <[email-masked]>, <[email-masked]>, Jim Martin <[email-masked]>, Randy Bush <[email-masked]>, Russ Housley <[email-masked]>
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    On 17 Jul 2017 8:26 a.m., "JORDI PALET MARTINEZ" <[email-masked]> wrote:

    

    Hi Jordi

    Perhaps we can try for 1 or 2 days for experiental purpose as need not to wait for final RFC and the outcome could also feed the current draft as is. Who knows.

    Cheers
    Noah

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Jul 2017 08:48:03 +0200

I don't actually know what the goal of the IETF network is other than to
provide connectivity.   Because of the vicissitudes of hotel topology, it
is often the case that IETF participants experience issues with the network
at least once or twice per IETF despite the best efforts (and they are
quite exceptional) of the NOC team.   I do not really see what the damage
is that you are hoping to protect against here.   Users who don't read the
NOC announcement?   No sympathy.   Sorry.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Jul 2017 08:51:29 +0200

So we agree to change the rules so that we use this network for every ID that want to experiment with it? Otherwise we discriminate among different authors …

I think is a really bad precedent.

Regards,
Jordi

-----Mensaje original-----
De: Ted Lemon <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 17 de julio de 2017, 8:48
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: IPv6 Ops WG <[email-masked]>, Jim Martin <[email-masked]>, Randy Bush <[email-masked]>, Suresh Krishnan <[email-masked]>, Russ Housley <[email-masked]>, Alissa Cooper <[email-masked]>
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    I don't actually know what the goal of the IETF network is other than to provide connectivity.   Because of the vicissitudes of hotel topology, it is often the case that IETF participants experience issues with the network at least once or twice per IETF despite the best efforts (and they are quite exceptional) of the NOC team.   I do not really see what the damage is that you are hoping to protect against here.   Users who don't read the NOC announcement?   No sympathy.   Sorry.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Jul 2017 08:53:13 +0200

I don't think this is a social justice issue.   Does the IETF think that
IPv6 works, or not?   If we think it works, and we have been working for
what, 20 years, to make it work, and we have designed all this great
transition tech, then why on earth would we not want to use it?   This
isn't "one draft."   This is roughly half the work of the IETF for the past
two decades.

On Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTINEZ <
[email-masked]> wrote:

> So we agree to change the rules so that we use this network for every ID
> that want to experiment with it? Otherwise we discriminate among different
> authors …
>
> CC: IPv6 Ops WG <[email-masked]>, Jim Martin <[email-masked]>, Randy
> Bush <[email-masked]>, Suresh Krishnan <[email-masked]>, Russ
> Housley <[email-masked]>, Alissa Cooper <[email-masked]>
>     I don't actually know what the goal of the IETF network is other than
> to provide connectivity.   Because of the vicissitudes of hotel topology,
> it is often the case that IETF participants experience issues with the
> network at least once or twice per IETF despite the best efforts (and they
> are quite exceptional) of the NOC team.   I do not really see what the
> damage is that you are hoping to protect against here.   Users who don't
> read the NOC announcement?   No sympathy.   Sorry.
>
>
>
>
>

---

From: Noah <[email-masked]>
Date: Mon, 17 Jul 2017 10:01:44 +0300

FWIW and to cater for all, would a fallback dual stack SSID work for the
status quo while this 2nd v6 SSID is also experimented upon which is a
great idea considering this is IETF.

Noah

---

From: "Brzozowski, John" <[email-masked]>
Date: Mon, 17 Jul 2017 08:13:55 +0000

Agree with Noah and Ted.

Note the I-D explicitly documents that a fallback, dual stack SSID must remain available as Noah mentions below.

I fail to see how doing this will harm or discriminate.

We do need to eat our own dogfood, otherwise we are hypocrites.

John
+1-484-962-0060

From: v6ops <[email-masked]> on behalf of Noah <[email-masked]>
Date: Monday, July 17, 2017 at 09:01
To: Ted Lemon <[email-masked]>
Cc: Randy Bush <[email-masked]>, v6ops <[email-masked]>, Alissa Cooper <[email-masked]>, Russ Housley <[email-masked]>, Jim Martin <[email-masked]>, Suresh Krishnan <[email-masked]>
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

FWIW and to cater for all, would a fallback dual stack SSID work for the status quo while this 2nd v6 SSID is also experimented upon which is a great idea considering this is IETF.

Noah

On 17 Jul 2017 9:54 a.m., "Ted Lemon" <[email-masked]<mailto:[email-masked]>> wrote:
I don't think this is a social justice issue.   Does the IETF think that IPv6 works, or not?   If we think it works, and we have been working for what, 20 years, to make it work, and we have designed all this great transition tech, then why on earth would we not want to use it?   This isn't "one draft."   This is roughly half the work of the IETF for the past two decades.

On Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTINEZ <[email-masked]<mailto:[email-masked]>> wrote:
So we agree to change the rules so that we use this network for every ID that want to experiment with it? Otherwise we discriminate among different authors …

Regards,
Jordi

-----Mensaje original-----
De: Ted Lemon <[email-masked]<mailto:[email-masked]>>
Responder a: <[email-masked]<mailto:[email-masked]>>
Fecha: lunes, 17 de julio de 2017, 8:48
Para: JORDI PALET MARTINEZ <[email-masked]<mailto:[email-masked]>>
CC: IPv6 Ops WG <[email-masked]<mailto:[email-masked]>>, Jim Martin <[email-masked]<mailto:[email-masked]>>, Randy Bush <[email-masked]<mailto:[email-masked]>>, Suresh Krishnan <[email-masked]<mailto:[email-masked]>>, Russ Housley <[email-masked]<mailto:[email-masked]>>, Alissa Cooper <[email-masked]<mailto:[email-masked]>>
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

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

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

---

From: Gert Doering <[email-masked]>
Date: Mon, 17 Jul 2017 10:16:13 +0200

Hi,

> We do need to eat our own dogfood, otherwise we are hypocrites.

This.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Jul 2017 10:17:45 +0200

However, we have different ways for doing the same, and we should go for the one that has less impact and it is more realistic.

In the real world, you will not disable IPv4 in the LANs of end-users or enterprise customers (at least not now, may be in 3-5 years from now). This is what IETF need to test now. IPv6 only with IPv4 as a service (which is 464XLAT).

Again, and I’m for-IPv6, but being realistic, not considering sci-fi of turning down IPv4 in our customer networks (now).

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de "Brzozowski, John" <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 17 de julio de 2017, 10:14
Para: Noah <[email-masked]>, Ted Lemon <[email-masked]>
CC: Jim Martin <[email-masked]>, IPv6 Ops WG <[email-masked]>, Alissa Cooper <[email-masked]>, Russ Housley <[email-masked]>, Randy Bush <[email-masked]>, Suresh Krishnan <[email-masked]>
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    Agree with Noah and Ted.

     
     
    John
    
    +1-484-962-0060
     
    From:
    v6ops <[email-masked]> on behalf of Noah <[email-masked]>

    
    Noah

    
    I don't think this is a social justice issue.   Does the IETF think that IPv6 works, or not?   If we think it works, and we have been working for what, 20 years, to make it work, and we have designed all this great
     transition tech, then why on earth would we not want to use it?   This isn't "one draft."   This is roughly half the work of the IETF for the past two decades.

    On Mon, Jul 17, 2017 at 8:51 AM, JORDI PALET MARTINEZ <[email-masked]> wrote:

    
    Regards,
    Jordi

    -----Mensaje original-----
    De: Ted Lemon <[email-masked]>
    Responder a: <[email-masked]>
    Fecha: lunes, 17 de julio de 2017, 8:48
    Para: JORDI PALET MARTINEZ <[email-masked]>
    CC: IPv6 Ops WG <[email-masked]>, Jim Martin <[email-masked]>, Randy Bush <[email-masked]>, Suresh
     Krishnan <[email-masked]>, Russ Housley <[email-masked]>, Alissa Cooper <[email-masked]>
    Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
    
        I don't actually know what the goal of the IETF network is other than to provide connectivity.   Because of the vicissitudes of hotel topology, it is often the case that IETF participants experience issues with the
     network at least once or twice per IETF despite the best efforts (and they are quite exceptional) of the NOC team.   I do not really see what the damage is that you are hoping to protect against here.   Users who don't read the NOC announcement?   No sympathy. 
      Sorry.

    
    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: Fred Baker <[email-masked]>
Date: Mon, 17 Jul 2017 10:22:13 +0200

> On Jul 17, 2017, at 10:17 AM, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 

In the real world, there are networks that are doing this now.

---

From: Jen Linkova <[email-masked]>
Date: Mon, 17 Jul 2017 18:30:26 +1000

> In my opinion such kind of experiment should be only done once we approve the document as RFC, note before, so by the next IETF meeting (hopefully).

I'm not sure I understand the logic here.
The I-D is documenting the operational experience and actually I
believe it would make more sense to run the experiment *before*
finalizing the text/publish it as RFC to avoid the situation when  we
publish an RFC on smth we have not even done yet.

> We like it or not, this is not a valid option, unless we make sure that if some participants have troubles, the alternative SSIDs have other 2.4 and 5 GHz radios available. Is that the case?

I believe the draft clearly states the the fallback option needs to be
available.

> The way you’re proposing, will mean that many folks may switch to alternative SSID, or simply don't report those failures, so at the end you don’t have any results of how much is not working, etc.

Actually if the fallback dual-stack network requires an explicit
configuration on the client side (as the draft recommends) to avoid
users connecting to it accidentally, the number of clients falling
back to the dual stack SSID is very good data point to demonstrate
what % of users are experiencing issues.

-- 
SY, Jen Linkova aka Furry

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Jul 2017 10:30:35 +0200

Have you ever actually used the ietf-nat64 network?   What problems did you
have?   I ask because I use it at every IETF, and I never have any
problems.   So the degree of fear that you are exhibiting about having it
be the default is really surprising to me.   This is really not a big deal,
except in the sense that it's a big deal that the IETF still isn't
dogfooding at meetings twenty years later.

On Mon, Jul 17, 2017 at 10:17 AM, JORDI PALET MARTINEZ <
[email-masked]> wrote:

> However, we have different ways for doing the same, and we should go for
> the one that has less impact and it is more realistic.
>
> In the real world, you will not disable IPv4 in the LANs of end-users or
> enterprise customers (at least not now, may be in 3-5 years from now). This
> is what IETF need to test now. IPv6 only with IPv4 as a service (which is
> 464XLAT).
>
> Again, and I’m for-IPv6, but being realistic, not considering sci-fi of
> turning down IPv4 in our customer networks (now).
>
> Regards,
> Jordi
>
>
> CC: Jim Martin <[email-masked]>, IPv6 Ops WG <[email-masked]>, Alissa
> Cooper <[email-masked]>, Russ Housley <[email-masked]>, Randy
> Bush <[email-masked]>, Suresh Krishnan <[email-masked]>
>     Note the I-D explicitly documents that a fallback, dual stack SSID
> must remain available as Noah mentions below.
>
>     Cc: Randy Bush <[email-masked]>, v6ops <[email-masked]>, Alissa Cooper
> <[email-masked]>, Russ Housley <[email-masked]>, Jim Martin <
> [email-masked]>, Suresh Krishnan <[email-masked]>
>     FWIW and to cater for all, would a fallback dual stack SSID work for
> the status quo while this 2nd v6 SSID is also experimented upon which is a
>     I don't think this is a social justice issue.   Does the IETF think
> that IPv6 works, or not?   If we think it works, and we have been working
> for what, 20 years, to make it work, and we have designed all this great
>      transition tech, then why on earth would we not want to use it?
>  This isn't "one draft."   This is roughly half the work of the IETF for
> the past two decades.
>
>
>     So we agree to change the rules so that we use this network for every
> ID that want to experiment with it? Otherwise we discriminate among
> different authors …
>
>      Krishnan <[email-masked]>, Russ Housley <
> [email-masked]>, Alissa Cooper <[email-masked]>
>         I don't actually know what the goal of the IETF network is other
> than to provide connectivity.   Because of the vicissitudes of hotel
> topology, it is often the case that IETF participants experience issues
> with the
>      network at least once or twice per IETF despite the best efforts (and
> they are quite exceptional) of the NOC team.   I do not really see what the
> that any disclosure, copying, distribution or

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Jul 2017 10:32:14 +0200

> what % of users are experiencing issues.

Yes!

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Jul 2017 10:33:35 +0200

May be, but it means that customers with use old apps with literals, go and complain to their operators, and probably switch to another operator. I don’t think this is a good advice to operators or enterprise network admins to deploy IPv6-only in their LANs.

I fully agree about IPv6-only in the WAN and IPv4 as a service in the LANs.

Regards,
Jordi

---

From: Jen Linkova <[email-masked]>
Date: Mon, 17 Jul 2017 18:34:15 +1000

On Mon, Jul 17, 2017 at 6:17 PM, JORDI PALET MARTINEZ
<[email-masked]> wrote:
> In the real world, you will not disable IPv4 in the LANs of end-users or enterprise customers (at least not now, may be in 3-5 years from now).

I disagree with this statement. There are networks doing this. Right
here right now.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Jul 2017 10:35:12 +0200

We may need to clarify the goal here:

Is just to experiment this ? Then it has been widely done, no doubt.

Or it is to measure what apps fail? Then CLAT is a better way, as you can measure/log it automatically.
 
Regards,
Jordi

---

From: Mark Elkins <[email-masked]>
Date: Mon, 17 Jul 2017 10:35:48 +0200

For what its worth, we've had successful IPv6 only days in past AfriNIC
meetings (using NAT64+DNS64). I also personally ran IPv6 only at a
SAFNOG (Southern African NOG) in Swaziland with no ill effects (I broke
dhcp on my Laptop and just had to once configured the IPv6 Nameservers
by hand).

I'm personally advocating having future "IPv6 only" AfriNIC meetings
though this may end up being just for a single day.

-- 
Mark James ELKINS  -  Posix Systems - (South) Africa
[email-masked]       Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Jul 2017 10:37:03 +0200

Tell your bank, your university, your library, etc., to try that.

I now that some networks (mainly related to IETF work, vendors, etc.), are doing that, but not in a general market.

Regards,
Jordi

---

From: David Schinazi <[email-masked]>
Date: Mon, 17 Jul 2017 10:38:45 +0200

> On Jul 17, 2017, at 10:34, Jen Linkova <[email-masked]> wrote:
> 
> <[email-masked] <mailto:[email-masked]>> wrote:

A major US carrier is doing this today on iPhone without any CLAT.
It works, and they don't even have a fallback.
What we're proposing here is allowing networking experts to test
the feasibility of IPv6 only. From my experience most issues are
extremely minor and it often only takes small fixes to work. But
you need to be aware of the issue ti go fix it.

Using a CLAT here would not allow us to learn what works or not
because going through NAT64 is not a failure.

Thanks,
David Schinazi

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

---

From: Stephen Honlue <[email-masked]>
Date: Mon, 17 Jul 2017 12:38:57 +0400

My take for this is: IPv6 only per the I-D for the balance of IETF week?

We have been standardizing IPv6 for over twenty years now, it's just so
logical to preach by example.

Regards.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Jul 2017 10:39:09 +0200

What we prefer:

1) Knowing only “how many” people switch to dual-stack fallback?
Or
2) Knowing what apps fail to operators with NAT64, which means we could tell the vendors of specific apps?

Regards,
Jordi

-----Mensaje original-----
De: Ted Lemon <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 17 de julio de 2017, 10:32
Para: Jen Linkova <[email-masked]>
CC: Jordi Palet Martinez <[email-masked]>, Randy Bush <[email-masked]>, "[email-masked]" <[email-masked]>, Russ Housley <[email-masked]>, Alissa Cooper <[email-masked]>, Jim Martin <[email-masked]>, Suresh Krishnan <[email-masked]>
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    Yes!

---

From: Gert Doering <[email-masked]>
Date: Mon, 17 Jul 2017 10:40:40 +0200

Hi,

On Mon, Jul 17, 2017 at 10:33:35AM +0200, JORDI PALET MARTINEZ wrote:
> May be, but it means that customers with use old apps with literals, 
> go and complain to their operators, and probably switch to another 
> operator. I don???t think this is a good advice to operators or 
> enterprise network admins to deploy IPv6-only in their LANs.

This is not about "operators".  It's about demonstrating to a very
particular technical body where homeworks have not been made properly yet
- so: expose breakage to those that need to fix it.

IETF attendees are not innocent virgins that need to be protected from
evil dragons.

Gert Doering
        -- NetMaster

---

From: Jen Linkova <[email-masked]>
Date: Mon, 17 Jul 2017 18:41:35 +1000

> I now that some networks (mainly related to IETF work, vendors, etc.), are doing that, but not in a general market.

Are you saying IETF should wait until everyone else has done it and
proved it works and only then we feel safe enough to try it? ;)

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Jul 2017 10:42:01 +0200

Using CLAT means we can actually KNOW and report if we like, what will be broken by NAT64 without actually breaking it.

Cellular networks is a much more controlled field, I guess all app developers, because Apple mandated (and I like it very much), support for IPv6 in any app, worked out the same for Android/Windows apps, so it make sense.

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]> en nombre de David Schinazi <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 17 de julio de 2017, 10:38
Para: Jen Linkova <[email-masked]>
CC: Jordi Palet Martinez <[email-masked]>, Randy Bush <[email-masked]>, IPv6 Ops WG <[email-masked]>, Russ Housley <[email-masked]>, Alissa Cooper <[email-masked]>, Jim Martin <[email-masked]>, Suresh Krishnan <[email-masked]>
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    

    

    

    Thanks,
    David Schinazi

    
    -----Mensaje original-----
    De: v6ops <[email-masked]> en nombre de "Brzozowski, John" <[email-masked]>
    Responder a: <[email-masked]>
    Fecha: lunes, 17 de julio de 2017, 10:14
    Para: Noah <[email-masked]>, Ted Lemon <[email-masked]>
    CC: Jim Martin <[email-masked]>, IPv6 Ops WG <[email-masked]>, Alissa Cooper <[email-masked]>, Russ Housley <[email-masked]>, Randy Bush <[email-masked]>, Suresh Krishnan <[email-masked]>
    Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
    
       Agree with Noah and Ted.

    
    
       John
    
       +1-484-962-0060
    
       From:

    
       Noah

    

    
    
       Regards,
       Jordi

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Jul 2017 10:44:27 +0200

I’m saying:

1) We should not try experiments in the IETF network, it has been the rule for ages.
2) If we decide to change that rule, we should try what is good for the market, not what we “wish”

I wish we can turn off IPv4 for every network in the world, but this is not realistic.

Turning off IPv4 in the WAN, but keeping some sort of IPv4 connectivity, is feasible. This is what we need to try.

NAT64 has been tested, in fact most of the RIRs (and of course IETF), have already such a network from long time ago.

Saludos,
Jordi

---

From: Tore Anderson <[email-masked]>
Date: Mon, 17 Jul 2017 10:59:29 +0200

* JORDI PALET MARTINEZ <[email-masked]>

> However, we have different ways for doing the same, and we should go
> for the one that has less impact and it is more realistic.
> 
> In the real world, you will not disable IPv4 in the LANs of end-users
> or enterprise customers (at least not now, may be in 3-5 years from
> now). 

Jordi,

Did you even read the draft? It is quite clear in its recommendation to
provide IPv4 Internet connectivity to be provided through a NAT64/DNS64
service. Quoting from the abstract:

   The purpose of this document is to provide a blueprint and guidance
   for deploying IPv6-only Wi-Fi at IETF meetings.  This document
   outlines infrastructure and operational guidance that operators
   should consider when deploying IPv6-only networks **using NAT64 and
   DNS64 to support communication to legacy IPv4-only services**.

(Emphasis mine.)

> This is what IETF need to test now. IPv6 only with IPv4 as a service
> (which is 464XLAT).

Precisely. The existence of NAT64/DNS64 should in turn automatically
facilitate usage of 464XLAT.

Host operating systems that implements the CLAT component of 464XLAT
(e.g., Android or recently updated Windows 10) should be able to simply
activate it. While Apple doesn't implement 464XLAT per se they have
something similar, so they should be covered too.

There is more discussion about IPv4 backwards compatibility, including
a mention of 464XLAT, in section 4.2 of the draft.

Tore

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Jul 2017 11:06:27 +0200

Yeah, I read the draft and provided inputs.

And I understand what you’re saying however, not all the OSs have CLAT by default, it doesn’t work for us, and even less for end-customers.

I don’t think Apple has anything similar, just they mandated for iOS (smartphones), to have all the apps with IPv6 support, but is not the same for the laptops.

The last IETF I got a /64 prefix delegated by the NOC to my computer and I was running a VM with a CLAT daemon. All worked fine, but it requires the NOC to delegate me a prefix and have the VM running, which is not practical for every participant. Doing the same having the CLAT in a VM in the NOC itself, works for all.

Regards,
Jordi

-----Mensaje original-----
De: Tore Anderson <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 17 de julio de 2017, 11:00
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: IPv6 Ops WG <[email-masked]>, Jim Martin <[email-masked]>, Russ Housley <[email-masked]>, Suresh Krishnan <[email-masked]>, Alissa Cooper <[email-masked]>, Randy Bush <[email-masked]>
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    
    Jordi,

    
    (Emphasis mine.)

    

    Tore

---

From: David Schinazi <[email-masked]>
Date: Mon, 17 Jul 2017 11:07:10 +0200

> On Jul 17, 2017, at 10:59, Tore Anderson <[email-masked]> wrote:
> [...]

Indeed, section 4.2 mentions:

   Operating systems SHOULD provide simple
   ways for applications to do so or even connect to IPv4 literals in
   the absence of host names.  Possible solutions include 464XLAT
   [RFC6877], "Bump-in-the-Host" [RFC6535] and Happy Eyeballs v2 [HEv2].

Apple devices support HEv2, and this is massively deployed which
has proved that it is a viable solution.

David

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Jul 2017 11:41:20 +0200

I’ve investigated this with OpenVPN right now using the ietf-nat64 SSID.

The remote OpenVPN server is IPv4-only, has a domain name (so not using literals), however, it seems the name is resolved to the IPv4-only address (maybe not using Apple Sierra OS – latest version- all updated- system APIs), so it fails to work with the NAT64.

I’m sure there are many other apps that have the same problem, it is very unfortunate, I wish programmers do it right and use the systems APIs (and no literals) that make it work, but this is not the case in the real world.

The point here is again: Manually asking the participants that get something broken to report it, doesn’t work, while having an automated way to report what is using the CLAT is a much lower effort (actually none for the participants).

The result, if we do this experiment with NAT64, is that everyone requiring “any” app breaking with NAT64, is going to switch to the dual-stack SSID, so we will not get reports for “other” broken apps from those participants.

Is this what we want? Or we prefer to have as many reports of broken things as possible?

I guess many folks use OpenVPN, so it may be the case that many have the same problem. May be it happens the same with other VPN apps.

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]> en nombre de David Schinazi <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 17 de julio de 2017, 11:07
Para: Tore Anderson <[email-masked]>
CC: JORDI PALET MARTINEZ <[email-masked]>, Randy Bush <[email-masked]>, IPv6 Ops WG <[email-masked]>, Russ Housley <[email-masked]>, Alissa Cooper <[email-masked]>, Jim Martin <[email-masked]>, Suresh Krishnan <[email-masked]>
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    

    David

---

From: David Schinazi <[email-masked]>
Date: Mon, 17 Jul 2017 11:48:22 +0200

> On Jul 17, 2017, at 11:41, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 

Should we then give up on IPv6 or try to get these fixed?

> The point here is again: Manually asking the participants that get something broken to report it, doesn’t work, while having an automated way to report what is using the CLAT is a much lower effort…

Which "automated way to report what is [broken] using the CLAT" software are you referring to?

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Jul 2017 11:52:53 +0200

Definitively get them fixed, and towards that we need to identify them. We want to identify them “manually” or “automatically”? I think automatically will work much better. Manually means people may report the first failure, then switch to the fall back network …

CLAT can be run in a VM (for example using Jool). I’ve done it.

I’m not a software developer, but Jool provides some logging tools, it is just a matter to get our hands on it.

There may be other CLAT implementations that can be used. I think Jool is very powerful, take advantage of multiple cores, etc.

Regards,
Jordi

---

From: David Schinazi <[email-masked]>
Date: Mon, 17 Jul 2017 11:59:56 +0200

I absolutely agree that automatic issue detection is better.
However I fail to see how you automatically go from CLAT logs to
knowing there is an issue with a specific piece of software.
This is a problem that we tried to solve in the past and there is no silver bullet.

As such, I think relying on IETF attendees to check whether their own software works has great value.

David

> On Jul 17, 2017, at 11:52, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 
> 
> De: <[email-masked] <mailto:[email-masked]>> en nombre de David Schinazi <[email-masked] <mailto:[email-masked]>>
> Responder a: <[email-masked] <mailto:[email-masked]>>
> Para: <[email-masked] <mailto:[email-masked]>>
> CC: IPv6 Ops WG <[email-masked] <mailto:[email-masked]>>, Randy Bush <[email-masked] <mailto:[email-masked]>>, Alissa Cooper <[email-masked] <mailto:[email-masked]>>, Suresh Krishnan <[email-masked] <mailto:[email-masked]>>, Russ Housley <[email-masked] <mailto:[email-masked]>>, Jim Martin <[email-masked] <mailto:[email-masked]>>
> http://www.consulintel.es <http://www.consulintel.es/>
> The IPv6 Company
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Jul 2017 12:02:37 +0200

Everything that goes thru the CLAT means is failing to go thru the NAT64, so reporting all by default in the CLAT will make it.

The logs tell us the data that we need to identify the apps, and I think it could be automated with some scripts.

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]> en nombre de David Schinazi <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 17 de julio de 2017, 12:00
Para: <[email-masked]>
CC: IPv6 Ops WG <[email-masked]>, Randy Bush <[email-masked]>, Russ Housley <[email-masked]>, Suresh Krishnan <[email-masked]>, Alissa Cooper <[email-masked]>, Jim Martin <[email-masked]>
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    I absolutely agree that automatic issue detection is better.However I fail to see how you automatically go from CLAT logs to
    knowing there is an issue with a specific piece of software.
    This is a problem that we tried to solve in the past and there is no silver bullet.

    David

    

    
    Regards,
    Jordi

---

From: Tore Anderson <[email-masked]>
Date: Mon, 17 Jul 2017 12:04:36 +0200

> The remote OpenVPN server is IPv4-only, has a domain name (so not
> using literals), however, it seems the name is resolved to the
> IPv4-only address (maybe not using Apple Sierra OS – latest version-
> all updated- system APIs), so it fails to work with the NAT64.

Which OpenVPN version is this? If you're not running v2.4.0 or newer,
try upgrading. I believe this this have improved there, cf.
https://github.com/OpenVPN/openvpn/blob/release/2.4/Changes.rst:

[...]

  Dualstack round-robin DNS client connect
    Instead of only using the first address of each --remote OpenVPN
    will now try all addresses (IPv6 and IPv4) of a --remote entry.

[...]

  * proto udp and proto tcp now use both IPv4 and IPv6. The new options
    proto udp4 and proto tcp4 use IPv4 only.

Tore

---

From: Noah <[email-masked]>
Date: Mon, 17 Jul 2017 13:18:27 +0300

On 17 Jul 2017 11:36 a.m., "Mark Elkins" <[email-masked]> wrote:

+1 Elkins

And perhaps the upcoming meeting in November and hence forth but will
depend on the upstream provider sponsoring the connectivity.

Let us walk the talk folks.

Noah

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Jul 2017 12:23:13 +0200

Using latest version, both at the server and client. I will check later what specific version on both sides, but they are using >2.4.2 for sure.

Regards,
Jordi

-----Mensaje original-----
De: Tore Anderson <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 17 de julio de 2017, 12:04
Para: <[email-masked]>
CC: <[email-masked]>
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    
    
    [...]

    [...]

    Tore

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Jul 2017 12:26:03 +0200

OpenVPN requires that the client be configured to use either IPv4 or IPv6.
  If you configure the client to use IPv6, it will work just fine through
NAT64 to an IPv4 OpenVPN server.   This is an unfortunate limitation of
OpenVPN; the maintainers are aware of it, but apparently it's not a
priority to fix. :(

On Mon, Jul 17, 2017 at 12:23 PM, JORDI PALET MARTINEZ <
[email-masked]> wrote:

> Using latest version, both at the server and client. I will check later
> what specific version on both sides, but they are using >2.4.2 for sure.
>
> Regards,
> Jordi
>
>

---

From: Gert Doering <[email-masked]>
Date: Mon, 17 Jul 2017 12:42:53 +0200

Hi,

On Mon, Jul 17, 2017 at 11:41:20AM +0200, JORDI PALET MARTINEZ wrote:
> I???ve investigated this with OpenVPN right now using the ietf-nat64 SSID.
> 
> The remote OpenVPN server is IPv4-only, has a domain name (so not using literals), however, it seems the name is resolved to the IPv4-only address (maybe not using Apple Sierra OS ??? latest version- all updated- system APIs), so it fails to work with the NAT64.

The openvpn client in version 2.3.x is "dual single-stacked" - it will
not ask for a v6 address unless it's told to use ipv6 (in which case it
will not ask for a v4 address).  This obviously stinks, but you need
test setups like this to find out where it stinks.

Since this was found a few years ago at a RIPE meeting in the IPv6-only
network already, OpenVPN 2.4.x has been fixed, and will now do the right
thing ("call getaddrinfo() and use all addresses returned in the order
presented by the host OS").

Please upgrade your client :-)

> I???m sure there are many other apps that have the same problem, it is very unfortunate, I wish programmers do it right and use the systems APIs (and no literals) that make it work, but this is not the case in the real world.
> 
> The point here is again: Manually asking the participants that get something broken to report it, doesn???t work, while having an automated way to report what is using the CLAT is a much lower effort (actually none for the participants).

So how would the CLAT know that it's openvpn that is broken, and what
are meeting ops supposed to do with the result?

No, the breakage must be visible on the host that has broken software
installed, otherwise people will continue to just not care.

> I guess many folks use OpenVPN, so it may be the case that many have the same problem. May be it happens the same with other VPN apps.

OpenVPN is a good example, because the problem was found due to usage of
IPv6-only networks, fixed, and now just lingers because people continue
to use old versions...

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Mon, 17 Jul 2017 12:44:11 +0200

Hi,

> Using latest version, both at the server and client. I will check later what specific version on both sides, but they are using >2.4.2 for sure.

In which case the observed behaviour would only happen if you force
the client to IPv4-only by means of "proto udp4".

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Mon, 17 Jul 2017 12:45:38 +0200

Hi,

> OpenVPN; the maintainers are aware of it, but apparently it's not a

It has been fixed two years ago, and a formal release containing the
proper code has been made last December (2.4.0).

If there is anything still wrong in 2.4.x regarding dual-stack client
behaviour, I'd very much like to know.

Gert Doering
        -- NetMaster

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Jul 2017 13:32:35 +0200

Responding also to Gert.

I just tried again, no need to upgrade the client or server, as both of them were running the latest available versions.

As you said, it is a “strange” configuration “language”. Even if you don’t have the server with IPv6, it needs to be enabled in both sides to work thru a NAT64.

Of course, this means we “thechies” find the work around with some help from others that already suffered the problem, but a regular user not. If we were running CLAT, it just works and the most important, we get it reported/logged automatically, which is what I’m insisting on.

However …. I’m still on the ietf-nat64 and Outlook (last release 15.36) for Mac refuses to send this message. I need to turn to another SSID to keep working thru the meeting. This is what we want?

Regards,
Jordi

-----Mensaje original-----
De: Ted Lemon <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 17 de julio de 2017, 12:27
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: IPv6 Ops WG <[email-masked]>
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    OpenVPN requires that the client be configured to use either IPv4 or IPv6.   If you configure the client to use IPv6, it will work just fine through NAT64 to an IPv4 OpenVPN server.   This is an unfortunate limitation of OpenVPN; the maintainers are aware of it, but apparently it's not a priority to fix. :(
    
    On Mon, Jul 17, 2017 at 12:23 PM, JORDI PALET MARTINEZ <[email-masked]> wrote:

    Regards,
    Jordi

    -----Mensaje original-----
    De: Tore Anderson <[email-masked]>
    Responder a: <[email-masked]>
    Fecha: lunes, 17 de julio de 2017, 12:04
    Para: <[email-masked]>
    CC: <[email-masked]>
    Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    
    
        [...]

        [...]

        Tore

---

From: Gert Doering <[email-masked]>
Date: Mon, 17 Jul 2017 13:37:37 +0200

Hi,

On Mon, Jul 17, 2017 at 01:32:35PM +0200, JORDI PALET MARTINEZ wrote:
> As you said, it is a ???strange??? configuration ???language???. Even if you don???t have the server with IPv6, it needs to be enabled in both sides to work thru a NAT64.

Actually, no.  The server can be happily IPv4-only, but of course you
need to enable dual-stack mode on the client (which is the default, to
point this out explicitely).

If you force the client to IPv4-only "because the server is!", this is
what you'll get: something which is broken if you are in a DNS64/NAT64
network - but that's a misconfiguration, and there is no need to do so.

Same thing if you put a literal v4 address in your config - it's a 
misconfiguration, and it needs to break so people are made aware of it,
and can fix things.

(In your case it seems the VPN provider has created that config for you,
and if that provider puts "ipv4 only!" in the config, they need to be
told in no uncertain terms that this is a buggy client config - if the
DNS name resolves to v4-only, the client will automatically be v4-only,
so what)

> Of course, this means we ???thechies??? find the work around with some help from others that already suffered the problem, but a regular user not. If we were running CLAT, it just works and the most important, we get it reported/logged automatically, which is what I???m insisting on.
> 
> However ???. I???m still on the ietf-nat64 and Outlook (last release 15.36) for Mac refuses to send this message. I need to turn to another SSID to keep working thru the meeting. This is what we want?

This is what "we" *need*, otherwise it will just silently work and
nobody will ever escalate this high enough into Microsoft to fix it.

Gert Doering
        -- NetMaster

---

From: "Brzozowski, John" <[email-masked]>
Date: Mon, 17 Jul 2017 12:29:42 +0000

The below is not true, this is exactly what some of the author’s in the draft are doing:

“In the real world, you will not disable IPv4 in the LANs of end-users or enterprise customers (at least not now, may be in 3-5 years from now).”

The I-D that we wrote is based on real deployment experiences, not fantasy or sci-fi.

John
+1-484-962-0060

-----Original Message-----
From: v6ops <[email-masked]> on behalf of JORDI MARTINEZ <[email-masked]>
Reply-To: JORDI MARTINEZ <[email-masked]>
Date: Monday, July 17, 2017 at 10:17
To: v6ops <[email-masked]>
Cc: Jim Martin <[email-masked]>, Russ Housley <[email-masked]>, Suresh Krishnan <[email-masked]>, Alissa Cooper <[email-masked]>, Randy Bush <[email-masked]>
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    
    
    Regards,
    Jordi

    -----Mensaje original-----
    De: v6ops <[email-masked]> en nombre de "Brzozowski, John" <[email-masked]>
    Responder a: <[email-masked]>
    Fecha: lunes, 17 de julio de 2017, 10:14
    Para: Noah <[email-masked]>, Ted Lemon <[email-masked]>
    CC: Jim Martin <[email-masked]>, IPv6 Ops WG <[email-masked]>, Alissa Cooper <[email-masked]>, Russ Housley <[email-masked]>, Randy Bush <[email-masked]>, Suresh Krishnan <[email-masked]>
    Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
    
        Agree with Noah and Ted.

         
         
        John
        
        +1-484-962-0060
         
        From:

        
        Noah

        

        
        
        Regards,
        Jordi

---

From: "Brzozowski, John" <[email-masked]>
Date: Mon, 17 Jul 2017 12:29:43 +0000

Agreed.

John
+1-484-962-0060

From: v6ops <[email-masked]> on behalf of Ted Lemon <[email-masked]>
Date: Monday, July 17, 2017 at 10:30
To: JORDI MARTINEZ <[email-masked]>
Cc: Randy Bush <[email-masked]>, v6ops <[email-masked]>, Russ Housley <[email-masked]>, Alissa Cooper <[email-masked]>, Jim Martin <[email-masked]>, Suresh Krishnan <[email-masked]>
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

Have you ever actually used the ietf-nat64 network?   What problems did you have?   I ask because I use it at every IETF, and I never have any problems.   So the degree of fear that you are exhibiting about having it be the default is really surprising to me.   This is really not a big deal, except in the sense that it's a big deal that the IETF still isn't dogfooding at meetings twenty years later.

On Mon, Jul 17, 2017 at 10:17 AM, JORDI PALET MARTINEZ <[email-masked]<mailto:[email-masked]>> wrote:
However, we have different ways for doing the same, and we should go for the one that has less impact and it is more realistic.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]<mailto:[email-masked]>> en nombre de "Brzozowski, John" <[email-masked]<mailto:[email-masked]>>
Responder a: <[email-masked]<mailto:[email-masked]>>
Fecha: lunes, 17 de julio de 2017, 10:14
Para: Noah <[email-masked]<mailto:[email-masked]>>, Ted Lemon <[email-masked]<mailto:[email-masked]>>
CC: Jim Martin <[email-masked]<mailto:[email-masked]>>, IPv6 Ops WG <[email-masked]<mailto:[email-masked]>>, Alissa Cooper <[email-masked]<mailto:[email-masked]>>, Russ Housley <[email-masked]<mailto:[email-masked]>>, Randy Bush <[email-masked]<mailto:[email-masked]>>, Suresh Krishnan <[email-masked]<mailto:[email-masked]>>
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    Agree with Noah and Ted.

    John

    +1-484-962-0060<tel:%2B1-484-962-0060>

    From:
    v6ops <[email-masked]<mailto:[email-masked]>> on behalf of Noah <[email-masked]<mailto:[email-masked]>>
    Date: Monday, July 17, 2017 at 09:01
    To: Ted Lemon <[email-masked]<mailto:[email-masked]>>
    Cc: Randy Bush <[email-masked]<mailto:[email-masked]>>, v6ops <[email-masked]<mailto:[email-masked]>>, Alissa Cooper <[email-masked]<mailto:[email-masked]>>, Russ Housley <[email-masked]<mailto:[email-masked]>>, Jim Martin <[email-masked]<mailto:[email-masked]>>, Suresh Krishnan <[email-masked]<mailto:[email-masked]>>
    Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    Noah

    Regards,
    Jordi

---

From: "Brzozowski, John" <[email-masked]>
Date: Mon, 17 Jul 2017 12:29:44 +0000

Thank you.

John
+1-484-962-0060

-----Original Message-----
From: v6ops <[email-masked]> on behalf of Stephen Honlue <[email-masked]>
Date: Monday, July 17, 2017 at 10:38
To: v6ops <[email-masked]>
Subject: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    
    Regards.

---

From: Noah <[email-masked]>
Date: Mon, 17 Jul 2017 15:42:04 +0300

> what % of users are experiencing issues.

I couldnt agree more... Lets walk the talk folks.

So do we have consensus for the experiment to go on now that its pretty
much logical for folks across the board that this is good stuff?

Cheers,
Noah

---

From: Dmitry Burkov <[email-masked]>
Date: Mon, 17 Jul 2017 16:52:18 +0300

IETF did more funny things... It can do anything, of course...

---

From: Jen Linkova <[email-masked]>
Date: Mon, 17 Jul 2017 23:59:59 +1000

> 2) If we decide to change that rule, we should try what is good for the market, not what we “wish”

Could you pls elaborate on why proving that IPv6-only/NAT64 network
works (or if it does not, identifying the issues and getting them
fixed) is not good for the market? If, as you said, nobody is doing
Ipv6-only (and we have seen a number of comments stating the
opposite), wouldn't it be good for them if we prove that v6-only works
and start working on issues? If, as some people have said, there are
Ipv6-only network out >

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Jul 2017 16:08:07 +0200

To be clear, the reason to privilege nat64 is that it gives you effectively
an IPv6-only network, with enough of a shim that most stuff that still
relies on legacy servers still works.   It is not that nat64 is the
transition technology that the market has chosen (I don't actually know
what the market has selected) but rather that it is the transition
technology that allows us to not run _any_ IPv4 on the link.

On Mon, Jul 17, 2017 at 3:59 PM, Jen Linkova <[email-masked]> wrote:

> > Turning off IPv4 in the WAN, but keeping some sort of IPv4 connectivity,
> is feasible. This is what we need to try.
>
> >
> >
> > CC: IPv6 Ops WG <[email-masked]>, Jim Martin <[email-masked]>, Alissa
> Cooper <[email-masked]>, Suresh Krishnan <[email-masked]>,
> Russ Housley <[email-masked]>, Randy Bush <[email-masked]>
> >     > I now that some networks (mainly related to IETF work, vendors,
> etc.), are doing that, but not in a general market.
> >
> >     > CC: IPv6 Ops WG <[email-masked]>, Jim Martin <[email-masked]>,
> Russ Housley <[email-masked]>, Suresh Krishnan <
> [email-masked]>, Alissa Cooper <[email-masked]>, Randy Bush
> <[email-masked]>
> >     >     > In the real world, you will not disable IPv4 in the LANs of
> end-users or enterprise customers (at least not now, may be in 3-5 years
> from now).
> >     >
> >     >     > De: v6ops <[email-masked]> en nombre de
> "Brzozowski, John" <[email-masked]>
> >     >     > CC: Jim Martin <[email-masked]>, IPv6 Ops WG <
> [email-masked]>, Alissa Cooper <[email-masked]>, Russ Housley <
> [email-masked]>, Randy Bush <[email-masked]>, Suresh Krishnan <
> [email-masked]>
> >     >     >     Note the I-D explicitly documents that a fallback, dual
> stack SSID must remain available as Noah mentions below.
> >     >     >
> >     >     >     Cc: Randy Bush <[email-masked]>, v6ops <[email-masked]>,
> Alissa Cooper <[email-masked]>, Russ Housley <[email-masked]>,
> Jim Martin <[email-masked]>, Suresh Krishnan <[email-masked]>
> >     >     >     FWIW and to cater for all, would a fallback dual stack
> SSID work for the status quo while this 2nd v6 SSID is also experimented
> upon which is a great idea considering this is IETF.
> >     >     >
> >     >     >
> >     >     >
> >     >     >     Noah
> >     >     >
> >     >     >
> >     >     >
> >     >     >     I don't think this is a social justice issue.   Does the
> IETF think that IPv6 works, or not?   If we think it works, and we have
> been working for what, 20 years, to make it work, and we have designed all
> this great
> >     >     >      transition tech, then why on earth would we not want to
> use it?   This isn't "one draft."   This is roughly half the work of the
> IETF for the past two decades.
> >     >     >
> >     >     >
> >     >     >     So we agree to change the rules so that we use this
> network for every ID that want to experiment with it? Otherwise we
> discriminate among different authors …
> >     >     >
> >     >     >     CC: IPv6 Ops WG <[email-masked]>, Jim Martin <
> [email-masked]>, Randy Bush <[email-masked]>, Suresh
> >     >     >         I don't actually know what the goal of the IETF
> network is other than to provide connectivity.   Because of the
> vicissitudes of hotel topology, it is often the case that IETF participants
> experience issues with the
> >     >     >      network at least once or twice per IETF despite the
> best efforts (and they are quite exceptional) of the NOC team.   I do not
> really see what the damage is that you are hoping to protect against here.
>  Users who don't read the NOC announcement?   No sympathy.
> >     >     >       Sorry.
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     >     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
> >     >     > 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.
> >     >     >
> >     >     >
> >     >     >
> >     > 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: Mon, 17 Jul 2017 16:10:44 +0200

If the end-users and enterprises are forced to switch to IPv6 only in their LANs, overnight, who is going to pay for replacing IP cameras, home automation, and many other old devices, that still work, but are IPv4-only?

To make sure, IPv6-only in the WAN is not the same as IPv6-only in the WAN and the customers LANs.

If vendor x or z deploy IPv6-only infrastructure in their corporate network that’s really good and I applaud for it.

If cellular operator a or b deploy IPv6-only cellular access for smartphones, that's wonderful and I applaud it. It is a more controlled scenario and they can tell the app developers (as Apple did), to make sure that the apps are IPv6 capable. However, Android and Windows smartphones in that infrastructure are still using CLAT, right? Or Android/Windows have also done the same as Apple, making sure that all the Apps are IPv6-ready?

Now if instead of a smartphone is a LTE router, or a smartphone doing some kind of network sharing for providing broadband in a home that has no wired connectivity, and it is IPv6-only, how come are going to work those devices that I mention before? Should the user throw them to the trash can? Are the operators going to pay for that, or the user will prefer an operator that provides a broadband LTE router with some kind of “IPv4 as a service” in the LAN even if the WAN is IPv6-only?

Regards,
Jordi

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Jul 2017 16:13:05 +0200

If we count number of devices using it, the bigger one is 464XLAT. No other transition technology has reached the millions of devices connected with an IPv6-only WAN but still providing IPv4 as a service (just look at cellular operators in several countries, millions of users/devices).

Regards,
Jordi

-----Mensaje original-----
De: Ted Lemon <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 17 de julio de 2017, 16:09
Para: Jen Linkova <[email-masked]>
CC: Jordi Palet Martinez <[email-masked]>, Randy Bush <[email-masked]>, IPv6 Ops WG <[email-masked]>, Russ Housley <[email-masked]>, Alissa Cooper <[email-masked]>, Jim Martin <[email-masked]>, Suresh Krishnan <[email-masked]>
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    To be clear, the reason to privilege nat64 is that it gives you effectively an IPv6-only network, with enough of a shim that most stuff that still relies on legacy servers still works.   It is not that nat64 is the transition technology that the market has chosen (I don't actually know what the market has selected) but rather that it is the transition technology that allows us to not run _any_ IPv4 on the link.

    
    
    >     >     >     +1-484-962-0060 <tel:%2B1-484-962-0060>
    >     >     >
    >     >     >     From:

---

From: Tim Chown <[email-masked]>
Date: Mon, 17 Jul 2017 14:14:39 +0000

> On 17 Jul 2017, at 13:42, Noah <[email-masked]> wrote:
> 
> 
> So do we have consensus for the experiment to go on now that its pretty much logical for folks across the board that this is good stuff?

Sounds good to me. I’ve never had a problem with the IETF NAT64 network. I’d challenge those who have concerns to try it.  It’s not like there’s no fallback in place.

It’s also interesting - but I’d not make it the default - to try the IETF v6only SSID to gauge the v6 support for the tools you use on a regular basis, in your home or other 3rd party networks/services.  

Tim

---

From: David Schinazi <[email-masked]>
Date: Mon, 17 Jul 2017 16:15:43 +0200

Jordi,

464XLAT is the combination of a CLAT on the client and NAT64+DNS64 in the network.
This draft suggests operating the main IETF Wi-Fi as IPv6-only with NAT64+DNS64,
precisely so you can contact IPv4 servers using mechanisms like 464XLAT and HEv2.
I'm not sure what your point is.

David

> On Jul 17, 2017, at 16:13, JORDI PALET MARTINEZ <[email-masked]> wrote:
>

---

From: Jen Linkova <[email-masked]>
Date: Tue, 18 Jul 2017 00:23:35 +1000

> If the end-users and enterprises are forced to switch to IPv6 only in their LANs, overnight, who is going to pay for replacing IP cameras, home automation, and many other old devices, that still wo…

To be honest I'm a bit lost now. Does anything I've said makes you
think that we are suggesting to migrate ALL end-user devices and
enterprise network on this planet to IPv6-only overnight? If it does,
my apologies, it was not what I meant.
I do not believe that switching between two existing SSID at one
conference is going to have such a world-wide impact ;)

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Jul 2017 16:27:32 +0200

Ok, let me try to explain again …

1) We want to try IPv6-only with NAT64/DNS64 to detect broken apps.
2) This means people using this NAT64 network will spend some time if they have some apps that don’t work thru NAT64 and detect them, and report them to the NOC. Most folks will not necessarily be willing to do that, they will switch to the alternative SSID and keep working.
3) What I’m proposing is to use the same NAT64/DNS64 but at the same time provide a “CLAT” box in the same SSID (it can be made with Jool, I’ve a VM doing it already and I tested it in the previous IETF).
4) The result is the same, but people don’t need to spend time. We configure the Jool so it reports EVERY usage, so we can then process that file to detect WHAT was using the CLAT.
5) The result is the same as the suggested experiment, but NOT breaking anything, not asking the participants to report anything, but having BETTER collection of data about what will be broken if the CLAT is not there (anything that goes into the CLAT).

This network is “special” because most of the time, we have only laptops and smartphones, which may work in a high % (may be even 80-85%, just a guess), or we are able to “trick” it to work.

Real world networks (end-users and corporate which are not related to IETF), will not (in 3-5 years), be willing to replace all the apps and devices that fail with just NAT64. They need a CLAT or similar support in their LANs.

For example as indicated before, MSoffice for MAC is not working, so definitively anyone using it during the meeting, will need to switch to an alternative SSID. No reporting from anything else broken for those participants.

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]> en nombre de David Schinazi <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 17 de julio de 2017, 16:15
Para: <[email-masked]>
CC: IPv6 Ops WG <[email-masked]>, Randy Bush <[email-masked]>, Alissa Cooper <[email-masked]>, Suresh Krishnan <[email-masked]>, Russ Housley <[email-masked]>, Jim Martin <[email-masked]>
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    Jordi,

    David

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Jul 2017 16:30:01 +0200

Exactly!

So the dogfood that we need to try (now) is the one that can sever the “real” market, not the one that could serve the marked when they are ready to replace (in a big %) all the apps and devices that are IPv4 only. We could try this in a follow up phase (actually there is an SSID for that already).

Regards,
Jordi

---

From: Gert Doering <[email-masked]>
Date: Mon, 17 Jul 2017 16:30:27 +0200

Hi,

> If the end-users and enterprises are forced to switch to IPv6 only in their LANs, overnight, who is going to pay for replacing IP cameras, home automation, and many other old devices, that still wo…

What exactly does this have to do with the IETF meeting network?

(But if it turns out that the IETF bought gear that is v4 only, maybe
purchasing policies need to be reviewed)

Gert Doering
        -- NetMaster

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Jul 2017 16:36:36 +0200

If I understood correctly one of the main goals is to collect as much data as possible for broken apps.

Why doing it manually if it can be done automatically and we avoid disturbing anyone, which will mean that they will probably switch to the alternative SSID and stop reporting (as I needed to do myself because MS Office) ?

Regards,
Jordi

-----Mensaje original-----
De: Gert Doering <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 17 de julio de 2017, 16:30
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: IPv6 Ops WG <[email-masked]>, Jim Martin <[email-masked]>, Alissa Cooper <[email-masked]>, Suresh Krishnan <[email-masked]>, Russ Housley <[email-masked]>, Randy Bush <[email-masked]>
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    Hi,

    
    
    Gert Doering
            -- NetMaster

---

From: Philip Homburg <[email-masked]>
Date: Mon, 17 Jul 2017 16:41:24 +0200

> enterprise network on this planet to IPv6-only overnight? If it
> does, my apologies, it was not what I meant.  I do not believe that
> switching between two existing SSID at one conference is going to
> have such a world-wide impact ;)

If we assume that home wifi networks will remain dual stack for the next
couple of decades to support IPv4-only devices (the WAN link can be come
IPv6-only but the CPE will offer dual stack on wifi one way or another).

If we assume that most office wifi networks (and networks that connect measurement
equipment, industrial controllers, etc.) will do the same, then why would
we advocate that other wifi networks switch to a completely different way of
providing IPv4 connectivity?

Do we do that just to make sure that anything related to IPv6 is as confusing
as possible?

For extra confusion, we also call a network that supports NAT64 'IPv6-only'.
I guess that just to make sure that there is no way to describe a network that
really just provides IPv6 without any access to IPv4.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 17 Jul 2017 16:41:44 +0200 (CEST)

On Mon, 17 Jul 2017, JORDI PALET MARTINEZ wrote:

> So the dogfood that we need to try (now) is the one that can sever the 
> “real” market, not the one that could serve the marked when they are 
> ready to replace (in a big %) all the apps and devices that are IPv4 
> only. We could try this in a follow up phase (actually there is an SSID 
> for that already).

My android and iOS devices work great on IPv6 only using the proposed 
suggestion. My MacOS and Windows do not (because they don't have the 
464XLAT or bump-in-the-API that is available on the mobile platforms). I 
already know this. I don't need to prove it to anyone.

It's premature to go IPv6 only on the main wifi before main operating 
systems support the same mechanisms available on the mobile devices.

1. My "mosh" session only tries the same AF that it initially connected 
to. If I initially connected on an IPv4 network, it will never connect to 
anything on an IPv6 network.

2. My Windows VM which needs to reach IPv4 only resources have no way to 
do this through the Parallels NAT44. I would need a CLAT for this.

There are lots of desktop OS applications that do not work on IPv6 only 
DNS64+DNS64 without CLAT. I have tried this, it doesn't work, there is no 
need to do wider test. OS vendors need to implement CLAT (or equivalent) 
for it to be viable.

If the main wifi is going IPv6 only, I will run my mobile devices on it, 
but I will immediately swap to the dual stack SSID for my computer.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Jul 2017 16:43:10 +0200

I realize that Jordi is not satisfied by any of the responses to this
message that have been sent so far, and I don't want to minimize the
unfortunateness of that, but I do not think there is any change that
further discussion on the topic is going to result in that satisfaction
happening, and I don't think we are learning anything new by continuing the
discussion.   I am muting this thread now, so please do not take my
subsequent silence as agreement with Jordi's position.

On Mon, Jul 17, 2017 at 4:41 PM, Mikael Abrahamsson <[email-masked]>
wrote:

>> “real” market, not the one that could serve the marked when they are ready
>> to replace (in a big %) all the apps and devices that are IPv4 only. We
>> could try this in a follow up phase (actually there is an SSID for that
>> already).
>>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 17 Jul 2017 16:44:12 +0200

> data as possible for broken apps.

If the IPv6-only WiFi IETF experiment leads to installing a DHCPv6-PD 
server on the IETF network, and realisation that odhcp6c (DHCP client 
developped on openWRT) does not compile on Android because of a lacking 
libresolv - then I will be very happy.  It will probably help with maybe 
Android offering a working libresolv, and hence we can no longer say 
that DHCP-PD doesnt work on Android...  DHCP-PD is very important on 
cellular links.

Is there a DHCPv6-PD server on the IETF WiFi network?

Alex

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Jul 2017 16:55:44 +0200

Thanks to Mikael and Philip, seems that finally somebody understood my point … I didn’t expect it will be so hard to make it clear …

May be the question is what is the main goal of the experiment?

1) Just to FORCE us to run with NAT64 (then switch back – many of us - to an alternative SSID)
2) To detect AS MANY broken apps as possible

That brings to the right decision I guess.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Mikael Abrahamsson <[email-masked]>
Organización: People's Front Against WWW
Responder a: <[email-masked]>
Fecha: lunes, 17 de julio de 2017, 16:42
Para: IPv6 Ops WG <[email-masked]>
Asunto: Re: [v6ops] Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    

    

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

---

From: Jen Linkova <[email-masked]>
Date: Tue, 18 Jul 2017 01:08:21 +1000

> providing IPv4 connectivity?

I find it quite amusing how almost any IPv6-related problem turns out
to be a chicken and egg one.
'Nobody is using this because it is broken. It is broken because
nobody is using it'..

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Jul 2017 17:16:59 +0200

I see it in another way around:

1) I really want to get IPv6 deployed ASAP
2) I need to be in touch with market reality
3) This means IPv6-only WAN is feasible only if we keep some “minimum” IPv4 service in the LANs

Is not a chicken and egg. If we get ISPs having the possibility of deploying IPv6-only ASAP, with CPEs that run basic IPv4 service, and this not means investing in CGN and all kind of tricks to keep providing IPv4 service, we will succeed in increase the rate of IPv6 global traffic, which will push the vendors of any kind of devices to support IPv6, so later on, we could have *real* IPv6-only LANs as well.

Regars,
Jordi

---

From: Gert Doering <[email-masked]>
Date: Mon, 17 Jul 2017 17:17:25 +0200

Hi,

> anything on an IPv6 network.

This sounds like something that needs being worked on...  not much
different than the OpenVPN case - "stupid software, needs enough exposure
that people get annoyed and fix it".

Gert Doering
        -- NetMaster

---

From: Philip Homburg <[email-masked]>
Date: Mon, 17 Jul 2017 17:18:50 +0200

>'Nobody is using this because it is broken. It is broken because

I'm a very happy user of IPv6. No problem there.

Labeling IPv4 access as 'IPv6-only' provides the suggestion that this a actually
an IPv6 problem.

It isn't. This is a problem for people who want to stop supporting IPv4 but
realize that they have to keep supporting IPv4 for the next couple of decades.

What I find suprising is that people advocate supporting legacy IPv4 services
in a way that breaks how they are traditionally deployed. 

Oh yeah, we will support IPv4, but only if you upgrade each and every device 
that you expect to use IPv4 on.

---

From: Gert Doering <[email-masked]>
Date: Mon, 17 Jul 2017 17:23:45 +0200

Hi,

On Mon, Jul 17, 2017 at 05:18:50PM +0200, Philip Homburg wrote:
> Oh yeah, we will support IPv4, 

"Supporting unwilling remote endpoints" is something we cannot afford to
not-do in the next few years.

"Support unwilling applications" is something else, and their time is
running out.  If it can be done on the mobile world, why can it not 
be done in the windows or linux ecosystem?

IPv6-only with NAT64/DNS64 supports the first.

> but only if you upgrade each and every device that you expect to use IPv4 on.

So how many (client) devices do you have that have not been upgraded in the
last 10 years, and do not support IPv6, getaddrinfo(), and friends?

If IPv6 were something new, like "invented last year", that "expect 
devices to be upgraded" argument would be slightly more relevant than
for a protocol from last century.

Gert Doering
        -- NetMaster

---

From: Jen Linkova <[email-masked]>
Date: Tue, 18 Jul 2017 01:51:43 +1000

On Tue, Jul 18, 2017 at 12:41 AM, Mikael Abrahamsson <[email-masked]> wrote:
> suggestion. My MacOS and Windows do not (because they don't have the 464XLAT
> or bump-in-the-API that is available on the mobile platforms). I already
> know this. I don't need to prove it to anyone.

IMHO your email illustrates why exactly we need the proposed experiment.
Some people have said 'NAT64 does not work for me. It does not work
for most of the people here'.
Others said 'I've been using NAT64 SSID as a default one for years and
it works perfectly fine for me. Let's see if it's the case for others
and if it does not, what can be done to fix it'.
Let's go and get numbers.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 17 Jul 2017 18:03:32 +0200

>be done in the windows or linux ecosystem?

First, many people have devices they don't want to part with.

Second, some people may run old operating systems that need local network 
connectivity while on the same LAN other devices need full internet connectivity.

So no matter what, lots of wifi or 802.3 will have to have some form of 
'native' IPv4 support.

For an ISP it doesn't make sense to provide CPEs with native IPv4 support
to one group of customers and NAT64 to another.

So most likely ISP will hand out CPEs that provide native IPv4 for the next
couple of decades. There is no way ISPs can affort the supports calls if they
break too many legacy devices or setups.

>last 10 years, and do not support IPv6, getaddrinfo(), and friends?

How much code did you write that deals with IPv4 literals?

If the literal is already in binary form, you can use it directly. If you
already know that the literal is an IPv4 literal, then calling inet_pton is
way more convenient than calling getaddrinfo.

Next, if the application uses getaddrinfo but happens to be statically linked
with the getaddrinfo implementation then you are also out of luck.

So for most operating systems, something like 464XLAT makes most sense. You
want a 'socket(PF_INET, ...)' system call to work even if the application 
contains hand written assembly that makes the system call directly.

Operating systems started to include 464XLAT support only recently. And will take
a long time before essentially all operating systems have 464XLAT support. After
that it will take an enormous amount of time before all old devices
are either upgraded or retired.

And then what did we really achieve? Remove a tiny bit of code from CPEs and
related routers? Is it the religious IPv6 purity that demands that IPv4 native
needs to be killed as soon as possible?

>for a protocol from last century.

This is an edge case, but you don't want to know how much I had to change to the
Atlas probes and related infrastructure to get them to support NAT64/DNS64.

---

From: Jen Linkova <[email-masked]>
Date: Tue, 18 Jul 2017 02:06:11 +1000

On Tue, Jul 18, 2017 at 1:16 AM, JORDI PALET MARTINEZ
<[email-masked]> wrote:
> Is not a chicken and egg.

Let me clarify what I mean by the chicken and egg problem here.
'We can not turn off IPv4 because there are IPv4-only endpoints there
and they are not going away. Why those endpoints are not going away?
Because there is no demand for them to work on Ipv6-only networks. Why
there is
no demand for them to work on IPv6-only networks? Because nobody is
turning off IPv4'.

---

From: Erik Nygren <[email-masked]>
Date: Mon, 17 Jul 2017 12:25:58 -0400

I'll add to the list of problems I run into on the NAT64 network:  VPN with
split tunnelling and DNS sent through the VPN means the DNS64 gets
bypassed. I assume the same would hold true of clients overriding the
advertised DNS servers (eg, using Google DNS).

A local CLAT helps.  Ideally VPNs doing split tunnelling could be made
DNS64/NAT64 aware.  And apps being clever enough to do their own DNS should
ideally also resolve ipv4only.arpa via the system resolver to do their own
DNS64 synthesis.

- Erik.  (Torn on which ietf we start this with...)

     [Sent from my IPv6 connected T-Mobile 4G LTE mobile device]

---

From: Philip Homburg <[email-masked]>
Date: Mon, 17 Jul 2017 19:03:20 +0200

> 'We can not turn off IPv4 because there are IPv4-only endpoints
> there and they are not going away. Why those endpoints are not
> going away? Because there is no demand for them to work on Ipv6-only
> networks. Why there is no demand for them to work on IPv6-only
> networks? Because nobody is turning off IPv4'.

I find it fascinating that IPv6 is bad at competing with IPv4 even now
that IPv4 addresses have run out for a while, that you advocate actively
breaking IPv4.

---

From: Ca By <[email-masked]>
Date: Mon, 17 Jul 2017 17:04:03 +0000

On Mon, Jul 17, 2017 at 9:26 AM Erik Nygren <[email-masked]> wrote:

> I'll add to the list of problems I run into on the NAT64 network:  VPN
> with split tunnelling and DNS sent through the VPN means the DNS64 gets

Fyi, if you are running windows 10, just like Android, you may find you
have a local CLAT now that windows 10 has native support for 464xlat

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

The larger point is that common production Operating Systems are
increasingly functional without ipv4 or multiple types of ipv6-only
networks that present nat64 / dns64

---

From: Ca By <[email-masked]>
Date: Mon, 17 Jul 2017 17:17:28 +0000

> that IPv4 addresses have run out for a while, that you advocate actively
  ipv4 has been broken for 10 years now with the mass deployment of NAT.

User demans is irrelevant. We deploy ipv6only because we are out if ipv4
(in the real world). It is appropriet for the ietf to design and operate
real world scenarios instead of living in the legacy world abudent ipv4
addresses.

---

From: Gert Doering <[email-masked]>
Date: Mon, 17 Jul 2017 19:22:42 +0200

Hi,

> needs to be killed as soon as possible?

It's the extra effort required of running a dual-stack network.

"as soon as possible" was about 10 years ago, so that's out anyway.

But after 20 years of IPv6, it's really time to seriously work on killing
IPv4.  Which will, as you point out, take quite some time to finish - but
if you never start ("this is hard, nobody sane would be willing to do this,
people find it hart to part with their IPv4-only furbies, can we go fishing
instead?"), you'll never succeed.

In other words: it's either get rid of IPv4, or declare IPv6 to be a 
spectacular and costly fail, and get rid of that.  Customers pay more
to get their NAT444 fixed than for IPv6 deployment anyway.

Gert Doering
        -- NetMaster

---

From: Philip Homburg <[email-masked]>
Date: Mon, 17 Jul 2017 19:32:58 +0200

>real world scenarios instead of living in the legacy world abudent ipv4

If you are truely out of IPv4 address then you cannot deploy NAT64 so
the issue is moot.

If you do have enough public IPv4 addresses to deploy NAT64 then you can
just as well deploy any of the many other CGN techniques. Of course,
you may prefer to break legacy devices to promote IPv6. But that's then just
your choice.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 17 Jul 2017 19:49:47 +0200

>IPv4.  

In a world where most people have no access to IPv6. Where IPv6 deployment
is just slightly more than a blip on the radar. 

Yeah, there it is very obvious that we should start killing IPv4 support.

Convincing people that IPv6 is a good idea is already hard enough. So now
we tell them that they should really do 'IPv6-only' and break all unmodified
IPv4 hosts. That should really help IPv6 adoption.

---

From: Simon Hobson <[email-masked]>
Date: Mon, 17 Jul 2017 18:55:13 +0100

> that IPv4 addresses have run out for a while, that you advocate actively

That's not how I read it.
As I read it, "most" modern software(& systems/configs) will work with IPv4 or IPv6 - and for such software there is no problem as IPv4 gets turned off.
Also, as I read it from various comments, for those that don't, many are due to config issues (such as referencing an IPv4 address in OpenVPN config). It would be useful to identify such issues so that they can be corrected by educating those responsible.
And for those few bits of software where it's the software itself, then making the problem known would allow the developer to fix it "at some point" as they release new versions.

Fixing such problems leads to a situation where IPv6 only will actually work. The alternative that some seem to be advocating is to "do nothing" which means that such problems never get fixed, so IPv4 support stays as a requirement "forever", and progress doesn't happen.

My take on the proposal is that with an IETF shindig you have a self selected group of people with above average technical/networking knowledge - and a common interest in progress. As such it's a perfect group (ie people that won't just whine that "the internet's broken" with no useful information added) to try an experiment with and see whether it is practical to run such a network.

>   ipv4 has been broken for 10 years now with the mass deployment of NAT. 

Indeed, there seems to be a lot of argument about how to keep it working transparently when for the vast majority it only appears to work because of a lot of work behind the scenes to workaround what NAT breaks. In fact, a lot (not all, but a lot) of the modern complaint about surveillance and dependency on third parties continuing to provide servers (cf Zune and Revolv) is down to the need to workaround NAT.

Unfortunately, people don't believe anything is broken because of all this work that makes it appear as everything is working OK for them.

---

From: Simon Hobson <[email-masked]>
Date: Mon, 17 Jul 2017 19:08:32 +0100

> IPv4 hosts. That should really help IPv6 adoption.

"Break all unmodified hosts ?"
I was under the impression that many unmodified hosts (and the software running on them) was capable of running on an IPv6 only network - but there are specific, notable exceptions (OpenVPN config specific, and MS Outlook an Mac are two that have been mentioned), and that the scale is not clearly known.
If there is an experiment that will allow some insight into the scale of the issue, and with a self selected group who are likely to be able to provide more meaningful feedback than "internet's broken") then it's useful to be done.

And when people talk of "kill IPv4", I don't get the impression that they mean to literally get rid of it any time soon. Before you can get rid of it, a lot has to happen - and already mentioned, if you don't start that process then it'll never happen.
You've raised a good point - many people don't have IPv6 - that's one area to be addressed, and a good way of addressing that is to show that it's here, it's working, and the ISPs responsible really need to extract digit from posterior and start providing it.

I see a parallel with the old walled gardens like AOL, back when they were dial up and not internet connected. Many thought this new fangled internet thing, with it's complicated "IP addresses", was something to be ignored. Remember what happened to them ? it didn't happen overnight - but bit by bit they "went internet". First it was with "gateways", and eventually native IP - right now we are still at the "gateways" stage with IPv6 adoption, with many still stuck in the IPv4 walled garden, while many of us have this new fangled IPv6.

But if we sit back and wait, then those IPv4 walled gardens will remain, and the argument will be "but you can't kill it off" forever. I doubt if IPv4 will ever truly disappear (just as I still have some old kit doing AppleTalk !) - but it will get to the point where end users having to have it will be few and far between, eventually.
But, as Laozi said, "a journey of a thousand miles begins with a single step". A lot of people seem afraid of taking a single step, let alone a journey.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 17 Jul 2017 20:20:21 +0200

In your letter dated Mon, 17 Jul 2017 19:08:32 +0100 you wrote:
>I was under the impression that many unmodified hosts (and the software runnin
>g on them) was capable of running on an IPv6 only network - but there are spec
>ific, notable exceptions (OpenVPN config specific, and MS Outlook an Mac are t
>wo that have been mentioned), and that the scale is not clearly known.

I'll just assume that with 'IPv6 only' you mean NAT64/DNS64.

So the most obvious example that breaks with DNS64 is a web page that
refers to another http resource using an IPv4 literal. 

Anything that the user has done using IPv4 literals also breaks. Say the
address of a mail server, an ssh host, etc.

Of course, anyone who has manually configured Google's public DNS resolvers
is also in for a surprise.

---

From: Lee Howard <[email-masked]>
Date: Mon, 17 Jul 2017 20:54:56 -0400

On 7/17/17, 10:27 AM, "v6ops on behalf of JORDI PALET MARTINEZ"
<[email-masked] on behalf of [email-masked]> wrote:

>
>4) The result is the same, but people don’t need to spend time. We
>configure the Jool so it reports EVERY usage, so we can then process that
>file to detect WHAT was using the CLAT.

Your proposal is to log the 5-tuple of every connection (using the CLAT)
on the IETF network?
Any privacy concerns?

>5) The result is the same as the suggested experiment, but NOT breaking
>anything, not asking the participants to report anything, but having
>BETTER collection of data about what will be broken if the CLAT is not
>there (anything that goes into the CLAT).

I’m not sure that logging the 5-tuple (if that’s what you mean to log)
gives you that information.
For instance, if Outlook for Mac isn’t working, and we don’t know why,
then you may not see anything; the DNS lookup may happen over IPv6, and
OfM barfs without ever sending a packet. At most you’ll see a packet to an
SMTP/POP/IMAP port, but it won’t tell you whether it was the client or the
server that failed.
I’m not sure how to know of VPN failures where the DNS goes through the
VPN. 

>
>
>Real world networks (end-users and corporate which are not related to
>IETF), will not (in 3-5 years), be willing to replace all the apps and
>devices that fail with just NAT64. They need a CLAT or similar support in
>their LANs.

I don’t know how many corporate apps/devices fail with IPv6 + NAT64. Maybe
some legacy business systems, but that’s not the case for all, and won’t
be in 3-5 years. Even if it is, it may well make more sense for an
enterprise to use IPv6 on client networks, and surround legacy systems
with NAT64.

No, I don’t expect 90% of users will be doing IPv6-only in their homes or
corporate LANs in 3 years, but I wouldn’t be surprised if it’s 10-20%.

Lee

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Jul 2017 21:20:01 +0200

Below in-line with [Jordi].

    

[Jordi] I don’t have privacy concerns myself, but I understand that, and obviously whatever we do, I suggest to be anonymized.

After all if we do the other way, people will need to tell what apps and web sites or whatever are they visiting, so the issue is the same and we add the need for manual reporting.

    

[Jordi] I don't think we need to identify “why” something is not working. We just need to tell the “app” or “server” owner (example Microsoft in case of Outlook), what is failing. I don’t think is our job, neither we have, even if voluntary, resources to do more than that. So yes, maybe we need to log some additional data, such as port/protocol failing. We may need even to capture a few packets at the beginning of each traffic flow. I think I mention in one of the earlier emails I’m not a software developer, but I believe that we may figure out a simple way to do that if Jool itself don’t provides all the tools/data that we need.

[Jordi] Of course I was not suggesting to look into “VPN” traffic. My mention about OpenVPN was because first attempts it failed. So I was talking about OpenVPN as one app not surviving the NAT64, which now is sorted out.

    

[Jordi] There are many business with VoIP systems that will not work if they don’t have IPv4 (even with private addresses as they have today) in the LAN. Same for security systems (IP cameras), devices that check the time the people come in/out the office, office automation, lighting automation, and I can keep going like that. Same for apps, like business apps (older IBM systems still used very frequently here), banking apps, I’ve been in many situations of web sites with dual-stack (even for governments and banks) that don’t work with NAT64 (and of course, you can tell as many times you want to the bank or government, they will not sort out for you). So end of the history, we like it or not, we can’t have the corporate LANs with just NAT64 for a while, they need to keep private IPv4, even if they turn off IPv4 in the WAN.

    Lee

---

From: Erik Kline <[email-masked]>
Date: Tue, 18 Jul 2017 04:31:00 +0900

> is also in for a surprise.

Assuming the WKP is in use, they're free to manually assign the Google
Public DNS64 servers:

    https://developers.google.com/speed/public-dns/docs/dns64

Though that's just setting them up for a different surprise on other
networks.  :)

---

From: Tore Anderson <[email-masked]>
Date: Mon, 17 Jul 2017 23:23:59 +0200

* Philip Homburg

> you don't want to know how much I had to change to the Atlas probes
> and related infrastructure to get them to support NAT64/DNS64.
I do want to know, you certainly are tickling my curiosity here. Is this
about DNSSEC, did you implement a 464XLAT CLAT, or something else
entirely? If it cannot be summarised in an e-mail, perhaps write a RIPE
Labs article about the subject?

(I changed the subject, as to the best of my knowledge the Atlas probes
have their 802.11 radios disabled, and as such are very unlikely to ever
be connected to a conference wireless network.)

Tore

---

From: Philip Homburg <[email-masked]>
Date: Tue, 18 Jul 2017 09:48:06 +0200

>be connected to a conference wireless network.)

Let me start with the last part. Sometime ago we start working on support
for measuring eduroam. So there now exists firmware that can enable the
wifi radio and connect to a wireless network.

Note that by default, probes have firmware that does not contain any wireless
device drivers, etc.

We are working on a way for a probe host to opt in. At the moment we have
manually allowed wifi firmware  for some probes in educational institutions.
The only SSID we currently envision is eduroam. Though of course the
community can ask for others as well.

With this wifi capability it is easy to play around and connect a 'dev probe'
to the NAT64 network at a RIPE meeting.

So what goes wrong. Currently unsolved is that measurements are either v4
or v6. So if you measure a v4-only target with a v4 measurement then probes
on a NAT64 with never measure anything. You need a v6 measurement for that.

Then there was the problem that the system tries to be helpful. If you create
a v6 measurement and the target doesn't have a v6 address then the measurement
is not scheduled. Fortunately other people needed an override for that check
as well. 

The next thing is that the libraries used by the probe assume that DNS
resolvers are listed in /etc/resolv.conf. This is not entirely correct
if you have both a wired and wireless interface, but by and large it works.

Of course this completely fails when the wired interface is dual stack and
the wireless interface uses NAT64/DNS64.

Finally, traceroute output is extremely confusing and/or broken. I still have
to spend some time with some packets I captured during the RIPE meeting.

The reason is that IPv4 error ICMPs have to be converted to IPv6 error IMCPs.
But of course IPv4 error ICMPs do not adhere to all the requirements of
IPv6 error ICMPs. So this causes a protocol violation. And breaks some
assumptions in the Atlas traceroute code. I have no intent to solve that.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 20 Jul 2017 08:27:34 +0200 (CEST)

On Mon, 17 Jul 2017, Mikael Abrahamsson wrote:

> or bump-in-the-API that is available on the mobile platforms). I already know 
> this. I don't need to prove it to anyone.

I need to qualify the above statement. MacOS does have bump-in-the-API the 
same way as iOS has, but it's for the high-level APIs only. So when I 
connect my macbook to NAT64 wifi, safari works to use IPv4 literals, but 
Chrome does not (presumably because it uses the socket api).

So the problem is not that MacOS doesn't support NAT64 prefix synthesis, 
it's that most applications there don't use the APIs that actually do 
this.

---

From: Gert Doering <[email-masked]>
Date: Thu, 20 Jul 2017 08:29:59 +0200

Hi,

> on a NAT64 with never measure anything. You need a v6 measurement for that.

This is exactly the thing we ran into with OpenVPN being "doubly 
single-stacked" - and yes, for a measuring environment where you do
not want to rely on "use what getaddrinfo() is giving me", this is 
getting a bit tricky.

Gert Doering
        -- NetMaster