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

From: "Brzozowski, John" <[email-masked]>
Date: Mon, 17 Jul 2017 07:33:20 +0000

Apologies, I understand this mail did not make it to the various lists.

John
+1-484-962-0060

-----Original Message-----
From: John Brzozowski <[email-masked]>
Date: Sunday, July 16, 2017 at 20:28
To: "[email-masked]" <[email-masked]>
Cc: Randy Bush <[email-masked]>, Alissa Cooper <[email-masked]>, Jim Martin <[email-masked]>, Jari Arkko <[email-masked]>, Suresh Krishnan <[email-masked]>, Russ Housley <[email-masked]>
Subject: 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

---

From: Bill Fenner <[email-masked]>
Date: Fri, 28 Jul 2017 15:04:32 -0400

I understand there was a great deal of private discussion on this topic,
but none of it made it to the public lists.  Can someone who was involved
with the private discussion summarize it for this list?

Thanks,
  Bill

On Mon, Jul 17, 2017 at 3:33 AM, Brzozowski, John <
[email-masked]> wrote:

> To: "[email-masked]" <
> [email-masked]>
> Cc: Randy Bush <[email-masked]>, Alissa Cooper <[email-masked]>, Jim
> Martin <[email-masked]>, Jari Arkko <[email-masked]>, Suresh
> Krishnan <[email-masked]>, Russ Housley <[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:

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Jul 2017 13:38:20 -0700

I'm not very enthusiastic about this. People come to the IETF to do work
and having
to deal with potential bustage from this experiment gets in the way of that.

-Ekr

---

From: Ted Lemon <[email-masked]>
Date: Fri, 28 Jul 2017 17:17:06 -0400

On Jul 28, 2017, at 4:38 PM, Eric Rescorla <[email-masked]> wrote:
> I'm not very enthusiastic about this. People come to the IETF to do work and having

If you encounter bustage, you can switch to the legacy network.   You aren't the first person to raise this point, but I find it a bit perplexing.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 28 Jul 2017 17:40:22 -0400

Ted,

As one example, I have a VPN application over which I have no control that
I must use to reach corporate resources, including email. I haven’t yet had
a chance to try it with V6 and nat64, maybe it’ll work and maybe it won’t.
If it doesn’t, I’ll need to use the legacy network, which is currently
unencrypted. We would need to include a new SSID for an encrypted v4/v6
network (what we currently deliver on the “ietf” SSID). If that new SSID is
provided, then I’ll be OK with the migration.

Thanks,
Andy

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 28 Jul 2017 14:50:52 -0700

On 28 Jul 2017, at 14:17, Ted Lemon wrote:

> If you encounter bustage, you can switch to the legacy network.

The legacy network will have a different SSID. All laptops remember 
which SSIDs you have connected to successfully in the past. Thus, it is 
likely that if you encounter problems and have to switch to the 
example-ssid-legacy SSID, and you close your laptop to move to a new 
room and open it again, you'll be put back onto the ietf SSID.

The only way around this repeated problem is to *remove* the ietf SSID 
from the list of your trusted SSIDs. This is not only an additional 
step, but it is one that has effects on future IETF meetings.

Further, section 4.1 of the draft has no instructions for end users of 
various versions of various operating systems. The draft assumes that 
everyone attending an IETF meeting understands SLAAC and RA options and 
how they are set on their laptops: that assumption is demonstrably 
false, quite possibly for the majority of IETF attendees.

If we want to have a real dogfood test, the first step is documentation, 
not forced breakage for a significant portion of the attendees.

--Paul Hoffman

---

From: Ted Lemon <[email-masked]>
Date: Fri, 28 Jul 2017 18:20:02 -0400

On Jul 28, 2017, at 5:40 PM, Andrew G. Malis <[email-masked]> wrote:
> We would need to include a new SSID for an encrypted v4/v6 network (what we currently deliver on the “ietf” SSID). If that new SSID is provided, then I’ll be OK with the migration.

ietf-nat64 would be going away, so I don't think that would be a problem.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 28 Jul 2017 18:21:45 -0400

On Jul 28, 2017, at 5:50 PM, Paul Hoffman <[email-masked]> wrote:
> The legacy network will have a different SSID. All laptops remember which SSIDs you have connected to successfully in the past. Thus, it is likely that if you encounter problems and have to switch to the example-ssid-legacy SSID, and you close your laptop to move to a new room and open it again, you'll be put back onto the ietf SSID.

This is a good point.   Arguably, we should use a different SSID every IETF.   E.g., ietf-100 instead of ietf.   We're already proposing to do that for ietf-legacy so that people don't automatically associate with that ssid.

So if ietf goes away in favor of ietf-100, and ietf-hotel becomes ietf-100-hotel (or something like that), then would that address your objection?

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 28 Jul 2017 15:33:38 -0700

On 28 Jul 2017, at 15:21, Ted Lemon wrote:

> So if ietf goes away in favor of ietf-100, and ietf-hotel becomes 
> ietf-100-hotel (or something like that), then would that address your 
> objection?

That would fix the first problem, but your response skipped over the 
harder part:

--Paul Hoffman

---

From: Ted Lemon <[email-masked]>
Date: Fri, 28 Jul 2017 18:40:55 -0400

On Jul 28, 2017, at 6:33 PM, Paul Hoffman <[email-masked]> wrote:
> If we want to have a real dogfood test, the first step is documentation, not forced breakage for a significant portion of the attendees.

I don't actually know of any devices that would require manual configuration.   Maybe Linux with NetworkMangler?   If it were indeed the belief of the authors of the draft that any such configuration were required, I'm sure they would have mentioned it.   For any user for whom such configuration is required, I would argue that that user is experiencing brokenness, and should switch to the legacy network and report the problem, rather than attempting manual intervention.

The status quo as far as I am aware is that all modern operating systems support v6-only out of the box.   That's why this experiment makes sense now.   Even two years ago, that would not have been the case.   Hopefully nobody comes to IETF running unpatched, ancient software...

---

From: Dorian Kim <[email-masked]>
Date: Fri, 28 Jul 2017 18:42:26 -0400

Doesn’t this all assume being able to get functional IPv6 connectivity to IETF meeting sites?

-dorian

---

From: Ted Lemon <[email-masked]>
Date: Fri, 28 Jul 2017 19:00:04 -0400

> Doesn’t this all assume being able to get functional IPv6 connectivity to IETF meeting sites?

We've been doing that for a long time now.   Don't see any reason why it would be a problem in .sg.

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 28 Jul 2017 16:25:46 -0700

I assume – many of us are in the similar situation, especially those who use VPN access to their enterprises.

I’m all for v6 everywhere, however, in order to support those, who can’t be on v6, separate SSID should be provided, perhaps would be good to remind all IETF attendees – test your stuff on v6 only network, otherwise you might be out of luck in the future. Singapore however wouldn’t be the right point in time to switch v4 off completely.

My 0.2

Cheers,

Jeff

From: ietf <[email-masked]> on behalf of "Andrew G. Malis" <[email-masked]>
Date: Friday, July 28, 2017 at 14:41
To: Ted Lemon <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Brzozowski, John" <[email-masked]>, Suresh Krishnan <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: RESENDING - Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

Ted,

As one example, I have a VPN application over which I have no control that I must use to reach corporate resources, including email. I haven’t yet had a chance to try it with V6 and nat64, maybe it’ll work and maybe it won’t. If it doesn’t, I’ll need to use the legacy network, which is currently unencrypted. We would need to include a new SSID for an encrypted v4/v6 network (what we currently deliver on the “ietf” SSID). If that new SSID is provided, then I’ll be OK with the migration.

Thanks,

Andy

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 29 Jul 2017 00:53:47 +0100

> to deal with potential bustage from this experiment gets in the way of that.

+1

IIUC correctly this'd also break DNSSEC for some names and has to.
If so, I'd be against it.

S.

>> 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
>>     â€¢ 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?
>>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 28 Jul 2017 20:08:05 -0400

> If so, I'd be against it.

Yes, if your host doesn't do DNS64 and does do validation, you will get validation failures for signed A records.   I would argue that this is a broken configuration, but perhaps you would argue otherwise. :)

People who are forward-thinking (but not enough) in their use of DNSSEC and backward-thinking in their use of IPv6 will have problems.   It would be interesting to see if this produces operational problems in practice; if it does, I would expect people who ran into such problems to switch to the legacy network, and we would see that in the SSID usage.

Would you run into a problem in this case, if I may be so bold as to ask?

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 29 Jul 2017 01:16:34 +0100

> Would you run into a problem in this case, if I may be so bold as to ask?

Think so. I do have some DNSSEC-signed v4-only hosts with which I
like to chat and do validate. I can't claim the world will end if
I need to muck about to do that, but it a breakage that does not
represent backwards thinking.

S.

---

From: heasley <[email-masked]>
Date: Sat, 29 Jul 2017 00:35:32 +0000

> represent backwards thinking.

so, seems you should try it and fix/ticket/etc if it does not work, no?
its been discussed, i forget if on this or the 99-attendees list, that
its not sufficient to nurture v6 and its transition technologies by
simply switching to a v4 ssid nor to avoid using v6.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 28 Jul 2017 21:04:45 -0400

> represent backwards thinking.

The point is that if you are validating on your host, which I think is a great plan, you should also be doing DNS64 on your host; otherwise you will not be able to operate on a NAT64 network.   I guess the other option is to never do NAT64, but that's a bit extreme at the present time.   And, if you find that the current solution for doing DNS64 on your host isn't adequately secure, I would personally like you to complain about _that_, because that would likely provoke useful work.   :)

---

From: Randy Bush <[email-masked]>
Date: Sat, 29 Jul 2017 10:46:23 +0900

[ i do not speak for the noc ]

yes, this was discussed after seoul.  folk seemed to have this funny
idea that the meeting network is to facilitate getting work done.  i
hope you felt the chicago and praha networks were successful.

> so, seems you should try it and fix/ticket/etc if it does not work,
> no?  its been discussed, i forget if on this or the 99-attendees list,
> that its not sufficient to nurture v6 and its transition technologies
> by simply switching to a v4 ssid nor to avoid using v6.

in praha, as we had a second A10, we could finally consider nat64 to be
a production service.  we thank those who used, reported successes, and
ticketed problems.

the noc is very open to ideas on an easier/better way of reporting,
discussing, and tracking issues with the nat64 network in s'pore.  we
would like to make it as easy as possible for john and the nat64 folk to
track and deal with the equipment, software, and application vendors.

getting problems with nat64 identified, diagnosed, and fixed (or worked
around, sigh) is in the ietf's and the public's interest.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 29 Jul 2017 16:22:33 +1200

On 29/07/2017 13:46, Randy Bush wrote:
...
> around, sigh) is in the ietf's and the public's interest.

Sure. But dual stack operation is *not* the poor cousin. IMNSHO,
ipv6-only-with-NAT64-with-DNS64 is the poor cousin.

As a compromise, could we have:
1) *No* SSID called "ietf".
2) A secured SSID called "ietf-dual" for the dual stack service.
3) A secured SSID called "ietf-ipv6" for the ipv6+NAT64 service.
4) An insecure "ietf-legacy" that is a dual stack service.
5) The best you can manage for "ietf-hotel", preferably dual stack.

    Brian

---

From: "Patrik Fältström" <[email-masked]>
Date: Sat, 29 Jul 2017 07:02:48 +0200

On 29 Jul 2017, at 0:21, Ted Lemon wrote:

> Arguably, we should use a different SSID every IETF.   E.g., ietf-100 instead of ietf.

I am not recommending this.

ICANN is changing SSID every meeting, and it is a pain to get the meeting going.

If there is consensus to make the default SSID (let me call that "IETF") IPv6 only, then make "IETF" IPv6 only and add a new SSID that is called something else "WARNING-IPv4-ONLY-YES-I-KNOW-WHAT-I-AM-DOING" or something else that people manually can add and connect to if they have to.

   Patrik

---

From: Randy Bush <[email-masked]>
Date: Sat, 29 Jul 2017 16:42:28 +0900

so folk have some data to consider, as of tuesday about 08:00 gmt we had
seen the following unique associations (ietf-hotel excluded, as is not a
measure of choice)

1380 ietf
 967 ietf-legacy99
 611 eduroam
 226 ietf-2.4ONLY
 166 ietf-nat64
  62 ietf-v6ONLY

of course, a device could have been a serial associator, using more than
one network over the measured time period.

some suggested that the high count for legacy99 is partially due to some
devices automatically associating with unprotected networks.

i am not aware of a record of any later snapshot if one was recorded.
and we can not do further analyses now because we wipe all logs at the
end of the meeting just before backing them up (think PII).

randy

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 29 Jul 2017 05:53:38 -0700

> If you encounter bustage, you can switch to the legacy network.

Of course this is true, but it's equally true that the people who want to
use v6 only can use a separate network. It's not clear why those of us who
just want to get work done need to be inconvenienced in service of a
political point.

-Ekr

You aren't the first person to raise this point, but I find it a bit
> perplexing.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 29 Jul 2017 10:01:54 -0400

On Jul 29, 2017, at 8:53 AM, Eric Rescorla <[email-masked]> wrote:
> Of course this is true, but it's equally true that the people who want to use v6 only can use a separate network. It's not clear why those of us who just want to get work done need to be inconvenienced in service of a political point.

It's not a political point, Eric.

The point is that we claim that we have produced something that will Just Work for the average user.   If you really think you can't "get work done" on an IPv6-only network with working and functional transition tech, we have a problem.

So one of two things is true: you are right that such a network would not allow IETF attendees to "get work done," or you are wrong.   It would be good to know which of these is actually true.   This is the point of making it the default: so that you have to opt out rather than opting in.   That way we can see how many people opt out, and maybe get some feedback as to why.

Honestly, it's really frustrating to me how prevalent this idea is that getting things to work is someone else's problem.   You're the last person I would have expected to make this case.   Do you think that we should still be running TLS 1.1, and that trying to use TLS 1.3 when it becomes available would be a "political" choice?   That's essentially what you are arguing here, just in a different part of the stack.

---

From: Leif Johansson <[email-masked]>
Date: Sat, 29 Jul 2017 16:47:55 +0200

Skickat från min iPhone

> 29 juli 2017 kl. 16:01 skrev Ted Lemon <[email-masked]>:
> 

Or maybe that part of the stack spent less time making sure stuff worked before declaring mission accomplished.

---

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 29 Jul 2017 08:08:10 -0700

On 29 Jul 2017, at 7:01, Ted Lemon wrote:

>> Of course this is true, but it's equally true that the people who 
>> want to use v6 only can use a separate network. It's not clear why 
>> those of us who just want to get work done need to be inconvenienced 
>> in service of a political point.
>
> The point is that we claim that we have produced something that will 
> Just Work for the average user.

Who is this "we" you are speaking of? I know few people in the IETF who 
make that claim that about v6-only networks, and even fewer who do it 
with a straight face.

> If you really think you can't "get work done" on an IPv6-only network 
> with working and functional transition tech, we have a problem.

Again, that "we". The people who claim that v6-only networks are ready 
by default have a problem, not the IETF as a whole.

--Paul Hoffman

---

From: Ted Lemon <[email-masked]>
Date: Sat, 29 Jul 2017 11:08:21 -0400

Now *that *is political.

Sorry, Leif.   The deal is that the way you figure out whether something is
working is to try it.   If nobody is willing to try it, there's no way to
be sure that it's working.   The stack itself works fine, and we think the
ops part works too, but in order to *know* that it works, we have to try it.

Why is this such an upsetting idea?   Why is it necessary to make someone a
villain here?

On Sat, Jul 29, 2017 at 10:47 AM, Leif Johansson <[email-masked]> wrote:

> The point is that we claim that we have produced something that will Just
> Work for the average user.   If you really think you can't "get work done"
> on an IPv6-only network with working and functional transition tech, *we
> have a problem.*
>
> So one of two things is true: you are right that such a network would not
> allow IETF attendees to "get work done," or you are wrong.   It would be
> good to know which of these is actually true.   This is the point of making
> it the default: so that you have to opt out rather than opting in.   That
> way we can see how many people opt out, and maybe get some feedback as to
> why.
>
> Honestly, it's really frustrating to me how prevalent this idea is that
> getting things to work is someone else's problem.   You're the last person
> I would have expected to make this case.   Do you think that we should
> still be running TLS 1.1, and that trying to use TLS 1.3 when it becomes
> available would be a "political" choice?   That's essentially what you are
> arguing here, just in a different part of the stack.
>
>

---

From: Ted Lemon <[email-masked]>
Date: Sat, 29 Jul 2017 11:19:22 -0400

The reason you know of few people in the IETF who would make that claim is
that (1) the IETF is actually pretty backwards about trying new things, for
reasons about which I could speculate, but I'm sure that would be a bad
idea.   And (2) IETFers actually use a lot of stuff that regular users
never use, so we are more likely to run into breakage, e.g. Stephen's edge
case.   We are good people to use for testing edge cases.   And I think
most of us are fine with testing edge cases.   So I think that "we" is
actually a lot of IETF participants; however, those IETF participants tend
to avoid the IETF mailing list because discussions like this always devolve
into politics.

The IETF is in the business of designing new networking protocols.   If we
are so allergic to dogfood that we can't even tolerate it for a week at a
time three times a year, when there is an easy way to opt out, I think we
ought to just stop spending millions of tons of carbon every year flying to
these stupid meetings and go grow turnips or something.

On Sat, Jul 29, 2017 at 11:08 AM, Paul Hoffman <[email-masked]>
wrote:

>>> Of course this is true, but it's equally true that the people who want
>>> to use v6 only can use a separate network. It's not clear why those of us
>>> who just want to get work done need to be inconvenienced in service of a
>>> political point.
>>>
>>
>> Work for the average user.
>>
>
> make that claim that about v6-only networks, and even fewer who do it with
> a straight face.
>
> If you really think you can't "get work done" on an IPv6-only network with
>> working and functional transition tech, we have a problem.
>>
>
> Again, that "we". The people who claim that v6-only networks are ready by
> default have a problem, not the IETF as a whole.
>
> --Paul Hoffman
>

---

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 29 Jul 2017 08:44:45 -0700

On 29 Jul 2017, at 8:19, Ted Lemon wrote:

> most of us are fine with testing edge cases.

Exactly right. That's why many of us know first-hand that v6 has more 
hard-to-describe choices for end users than v4 does.

> So I think that "we" is

I was not thinking of just people on this mailing list: like you, I talk 
to many people at IETF meetings. I find few people who are not strong v6 
advocates saying that they think a v6-only is will Just Work for the 
average user.

> these stupid meetings and go grow turnips or something.

You can choose to do that if you want, of course: it's an individual 
choice. My preference is to keep developing networking protocols and 
seeing how they help Internet users over time.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 29 Jul 2017 16:51:06 +0100

> these stupid meetings and go grow turnips or something.

- I quite like the occasional turnip, but hate the idea of
having to grow the feckers:-)

- I'm also fine with dogfood, e.g the DPRIVE test last time
worked just fine for me - even though I had to switch DNS stuff
about when switching from ietf-hotel to gsm, I was ok with that
as it was an opt-in and I'd opted-in.

- I don't like the sound of the query logging in section 3.1
of the draft, but am confident that the NOC folks wouldn't do
something bad there. It'd still be good to see that properly
described before any switch over, esp if as a default, as I
guess the draft is really aimed at a bigger audience who may
not be as clueful about privacy as our NOC team.

- I have no clue if Ubuntu supports this now - section 4.2
of the draft doesn't fill me with confidence, and I'm puzzled
as to how the draft figures ssh will continue to work "without
incident" given known_hosts has v4 addresses. And opting-in
here will change the state of known_hosts I guess in a way
that might in principle lead to attacks (that said I've not
checked what ssh clients know about dns64/nat64).

The above "corner cases", (not that I agree they are:-), the
DNSSEC stuff already mentioned together and Randy's figures
imply to me that this isn't yet ready to be a default, and
ought remain an opt-in.

I might try it out next time though.

One other note: if there were a perceived benefit for the folks
opting-in that'd help your cause I think. "You can help us all
make this better" is not a sufficiently direct benefit to attract
that many dogfood eaters IMO.

Cheers,
S.

---

From: Leif Johansson <[email-masked]>
Date: Sat, 29 Jul 2017 18:22:45 +0200

Skickat från min iPhone

> 29 juli 2017 kl. 17:08 skrev Ted Lemon <[email-masked]>:
> 
> Now that is political.
> 
> Sorry, Leif.   The deal is that the way you figure out whether something is working is to try it.   If nobody is willing to try it, there's no way to be sure that it's working.   The stack itself works fine, and we think the ops part works too, but in order to know that it works, we have to try it.
> 

I was merely reacting to what I felt was a lopsided analogy between v6 (which has had ample time to get tested outside the IETF) and TLS 1.3. The latter is including *lots* of work on implementation and real-world testing in the WG workstream.

> Why is this such an upsetting idea?   Why is it necessary to make someone a villain here?

It isn't. I see no villains.

---

From: Richard Barnes <[email-masked]>
Date: Sat, 29 Jul 2017 12:31:00 -0400

This is not the Internet Debugging Task Force.  People come to IETF
meetings to get work done, not to debug operational issues.

Of course people should be doing research on operational impacts of the
protocols being developed, bringing the results of that research to the
relevant WGs, and adapting protocols to deal with them.  The TLS 1.3 work
has gone through this cycle several times.

However, just like the TLS 1.3 experimentation was not done on production
servers that were meant for doing actual work, neither is the IETF network
the right place to be discovering protocol issues.  If people want to opt
in, fine, but let's not make it the default.

On Sat, Jul 29, 2017 at 11:51 AM, Stephen Farrell <[email-masked]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 29 Jul 2017 18:53:08 +0200

+1

Exactly: despite how much I’m pro-IPv6 and not suspicious of being against it, and I agree we should try our own dogfood, I fully agree we MUST not force all the IETF participants to try it, as we aren’t the Debugging Task Force, unless we change our principles and clearly state that the IETF network must be considered experimental and in equal conditions for ANYONE willing to experiment on it, despite breaking anything for the rest.

Furthermore:
1) Even if we discover 100 of apps that get broken because the “IPv6-only” network, are we the Internet police or do we have a way to tell those apps developers to do it right?
2) If that’s the case, WHO is going to take the work for notifying the vendors/developers of those apps and making sure that they actually solve the problems?
3) We have a major problem here. We don’t have a real definition of what it means IPv6-only. If we believe that the world will run IPv6-only in the near 3-5 years, we are probably wrong, because we don’t have the power to make it happen. I agree we are turning into an IPv6-only access networks world, but we will keep LANs with dual-stack (with private IPv4 addresses and some transition mechanism in the access router) until 80% of the app developers are done and we can then start considering getting rid-off IPv4 at 100%.

If anyone is interesting in contributing to clarifying the concept of IPv6-only, please, comment in v6ops (pvt is ok too) about:

https://datatracker.ietf.org/doc/draft-palet-ietf-v6ops-ipv6-only/

Regards,
Jordi

-----Mensaje original-----
De: ietf <[email-masked]> en nombre de Richard Barnes <[email-masked]>
Responder a: <[email-masked]>
Fecha: sábado, 29 de julio de 2017, 18:31
Para: Stephen Farrell <[email-masked]>
CC: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
Asunto: Re: RESENDING - Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    This is not the Internet Debugging Task Force.  People come to IETF meetings to get work done, not to debug operational issues.  

    Of course people should be doing research on operational impacts of the protocols being developed, bringing the results of that research to the relevant WGs, and adapting protocols to deal with them.  The TLS 1.3 work has gone through this cycle several times.
    
    However, just like the TLS 1.3 experimentation was not done on production servers that were meant for doing actual work, neither is the IETF network the right place to be discovering protocol issues.  If people want to opt in, fine, but let's not make it the default.

    On Sat, Jul 29, 2017 at 11:51 AM, Stephen Farrell <[email-masked]> wrote:

    

    

    
    
    Cheers,
    S.

    

    

**********************************************
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: Christian Huitema <[email-masked]>
Date: Sat, 29 Jul 2017 09:53:43 -0700

> one network over the measured time period.
I may be a serial associator, since I connected my laptop to ietf,
ietf-nat64, and ietf-v6ONLY. The connection to "ietf" was automatic,
something the laptop remembered from time past. I purposely tried
ietf-v6only, because I like try stuff. Did not work well. One of the
servers I rely on is IPv4 only, and that was just not accessible. I fell
back to ietf-nat64, and it was OK.

So if the purpose of "eating our own dogfood" is to find out bugs and
breakage, here is a clear finding: IPv6 only networks do not provide
access to IPv4 only services today. NAT64 networks seem to work, but we
suspect that there are some drawbacks, such as messing up with DNSSEC,
and maybe also interfering with some P2P services.

So here I go with my $0.02 suggestion: moving the default to IPv6-only
won't work, but moving to NAT64 would mostly work. It would also
probably teach us what exactly is wrong with that technology.

-- 
Christian Huitema

---

From: Ted Lemon <[email-masked]>
Date: Sat, 29 Jul 2017 12:54:55 -0400

On Jul 29, 2017, at 11:44 AM, Paul Hoffman <[email-masked]> wrote:
> Exactly right. That's why many of us know first-hand that v6 has more hard-to-describe choices for end users than v4 does.

For the end user, there are no choices.   You plug your device into the network, and it works, or it doesn't.   What choices are you imagining?

> I was not thinking of just people on this mailing list: like you, I talk to many people at IETF meetings. I find few people who are not strong v6 advocates saying that they think a v6-only is will Just Work for the average user.

Forgive me, but it's always easy to put words in the mouths of people who aren't saying anything.   What you are saying here is that everyone who is silent on this topic agrees that IPv6 isn't going to Just Work for the end-user.   Do you see the flaw in your reasoning?

> checked what ssh clients know about dns64/nat64).

Right, so known_hosts is broken, because it remembers IP addresses.   This is something that ought to get fixed, not persisted.   Imagine how this feature interacts with the private service discovery feature that is being worked on in dnssd, when the host being connected to does IP address privacy.

I want _you_ in particular to use IPv6+nat64 because it will show you where some of the implementations of software that you currently use are broken, and then (I hope) you will get on board with trying to get them fixed.   That's the value proposition.   OpenVPN has known about their IPv6 brokenness for about four years, and they still haven't done anything about it.

> that many dogfood eaters IMO.

Right, that's why the "opt out" rather than "opt in" proposal.   We've had "opt in" since two Berlins ago, and we just don't get a lot of people trying the "opt in" network.   The value proposition is pretty obvious to me: we get to see how many people opt out.

> It isn't. I see no villains.

When you say that something that someone is trying to do that you disagree with is political, you are implicitly saying that there is a villain, and it is that bad person who is trying to do something for "political reasons".   Please don't do that.

IPv6 has had a lot more testing than TLS 1.3.

> On Jul 29, 2017, at 12:31 PM, Richard Barnes <[email-masked]> wrote:

>> However, just like the TLS 1.3 experimentation was not done on production servers that were meant for doing actual work, neither is the IETF network the right place to be discovering protocol issu…

The conclusion that I would draw from this argument is that you believe that nobody should ever use TLS 1.3, because it is new, and it will always be the case that at some point in the process end-users will be exposed to it for the first time, and possibly run into issues.   That sort of thing should never happen in production, hence TLS 1.3 should never be deployed.

That really is what you are saying.   The IETF has been running IPv6-only with NAT64 as a transition tech for about four years, and I'm guessing you've never opted in.   So your argument is basically "it's not my problem, and it will never be okay for us to run this in production, let's just keep using IPv4."

---

From: Randy Bush <[email-masked]>
Date: Sun, 30 Jul 2017 02:55:22 +0900

> Just Work for the average user.  If you really think you can't "get
> work done" on an IPv6-only network with working and functional
> transition tech, we have a problem.

bingo!  you are right.  we have a problem.  nat64/dns64 breaks things
people use.  this is known, documented, and extremely annoying this many
years out [0].

the question is how to progress fixing nat64/dns64, given that a lot of
folk come to ietf meetings to simply get work done and not debug a semi-
working transport.  how about a bug bounty?  and maybe a fix bounty a
few times larger!

randy

--

0 - for just how many years, see my plenary rant against 4966 a few
    chicagos back.  it is my $dayjob's customers, the enterprises, who
    are the main target of nat64/dns64, and i am not happy that they can
    not deploy it safely.

---

From: Tim Chown <[email-masked]>
Date: Sat, 29 Jul 2017 19:17:39 +0100

Hi,

There are many issues intertwined here. I think there are three of particular interest:

1. Which technology the ‘ietf’ SSID offers, as the ‘default’.

There’s some emotive language being used here, but ultimately the decision will not prevent anyone getting work done, so long as one production quality SSID can be selected.

What the decision does affect is the volume of data we obtain on the operation of NAT64/DNS64/464XLAT at the meeting. At IETF99, Randy’s data reported 1,380 ietf SSID users, and 166 ietf-nat64 SSID users, as of Tuesday morning.  And around 1,900 users with a device on a different SSID to those two. So as it stands, around 5% of device associations are to the NAT64 network.  

Would we like to raise the number of devices using the NAT64 network? If so, how, if not running the ietf SSD with it?

2. Whether we fully understand how devices of various common OSes select an SSID on startup, without manual intervention.

The line in Randy’s data that puzzled me was the 967 devices associating to the ietf-legacy99 SSID. I believe the SSID had the meeting number appended to avoid devices just re-associating to an ‘ietf-legacy’ SSID every meeting. By adding the number, one might hope users would have to manually select the SSID. But perhaps at least one major OS prefers this SSID because of its open property?

Understanding an OS’s SSID selection behaviour is important if we’re concerned about people having to manually set the production quality SSID, and to know that they won’t drift back to an undesired SSID while working or on a network (re)attachment.

3. How we capture and report the experiences of users / devices running NAT64/DNS64/464XLAT.

> and maybe also interfering with some P2P services.

A fair 10,000’ summary, probably. But what empirical evidence do we have? What data are we able to gather at an IETF meeting on the success or failures of NAT/64/DNS64 (and 464XLAT where also used), whether we have 166 devices on the NAT64 SSID, or 1,166 devices? And how can this data be publicly reported for everyone to learn and benefit from? 

Tim

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 29 Jul 2017 11:17:57 -0700

> It's not a political point, Eric.

We'll have to agree to differ, I suppose.

> way we can see how many people opt out, and maybe get some feedback as to

In other words, you want to opt everyone into doing your testing for you.
Again, that's not the purpose of the IETF network.

> arguing here, just in a different part of the stack.

No, it's not. The right analogy would be filtering out TLS 1.3 at our
network edge, which you absolutely do not see me suggesting.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 30 Jul 2017 00:17:32 +0100

Hi Ted,

On 29/07/17 17:54, Ted Lemon wrote:
> Right, so known_hosts is broken, because it remembers IP addresses.

I don't think that's likely to be a statement on which everyone agrees.

> This is something that ought to get fixed, not persisted.   Imagine
> how this feature interacts with the private service discovery feature
> that is being worked on in dnssd, when the host being connected to
> does IP address privacy.
> 
> I want _you_ in particular to use IPv6+nat64 because it will show you
> where some of the implementations of software that you currently use
> are broken, and then (I hope) you will get on board with trying to
> get them fixed.   That's the value proposition. 

See below, but I think value proposition is the wrong term above.

>  OpenVPN has known
> about their IPv6 brokenness for about four years, and they still
> haven't done anything about it.

I've used openvpn quite successfully in order to get IPv6 so I'm
not sure what brokenness you mean. (No, not for lots of traffic,
but it worked.)

>> opting-in that'd help your cause I think. "You can help us all make
>> this better" is not a sufficiently direct benefit to attract that
>> many dogfood eaters IMO.

> Right, that's why the "opt out" rather than "opt in" proposal.
> We've had "opt in" since two Berlins ago, and we just don't get a lot
> of people trying the "opt in" network.   The value proposition is
> pretty obvious to me: we get to see how many people opt out.

I don't think you got what I meant. Being able to opt-in to fixing
other people's bugs is not a value proposition that'll resonate. And
being opted-in and having to opt-out will only generate rancour.

Last time, with DPRIVE I got my DNS queries encrypted for at least
one hop, so that's a win, albeit a very very minor win, even for people
who know about it and care.

Fixing other people's bugs is frankly not in itself motivating.
Even moreso if we don't agree on which behaviours are bugs or
features;-)

So my question to you was really "what gets better for me if I use
that SSID?" If the answer is "things get worse" then yes you will
continue to have issues attracting people to try it, and so long as
that remains the answer it'll never be ready to be the default.

So I think this is very far from sufficient to justify an opt-out.

Cheers,
S.

---

From: Randy Bush <[email-masked]>
Date: Sun, 30 Jul 2017 09:15:32 +0900

> that remains the answer it'll never be ready to be the default.

why not start with what we have traditionally done with new protocols
and implementations, the nat64 aficionados conduct interop testing with
an i-d reporting the result?  for example, in the s'pore hackathon, have
a group with an assortment of devices and a wide assortment of
applications actually testing nat64.  maybe kickstart with the nat64
tickets from {seoul,chicago,praha} if no other ideas come to mind.

randy

---

From: Ted Lemon <[email-masked]>
Date: Sat, 29 Jul 2017 21:16:31 -0400

> that remains the answer it'll never be ready to be the default.

The IETF network is always going to have enough IPv4 addresses for every user.   Hence, it is _never_ going to be better for IETF users to use an IPv6-only network, because the main feature of IPv6 is end-to-end, and if you are still v4-privileged, you have end-to-end with v4, unlike the rest of the world.   So if that's the value proposition required to make v6-only the default, v6-only is not going to be the default until it becomes difficult to get clean v4 peering at IETF meetings.   That is, not anytime soon.

It looks like OpenVPN finally supported dual-stack servers with stack-agnostic clients roaming to v6-only networks as of 2.4/3.0.

OpenSSH shouldn't store IP addresses in known_hosts files because in the real world, 192.168.1.1 refers to a different host depending on what network I'm connected to.   So I wind up having to go in and delete these addresses from my known_hosts file on a regular basis.   It makes some sense to say that server.example.org <http://server.example.org/> should have a stable ssh key; it makes very little sense to say that some random IP address should have a stable key.

Best case, if the thing you're connecting to uses privacy addresses, you're going to have a key file with a _ton_ of stale keys; worse case, you're going to be in the habit of editing your known_hosts file to delete bogus keys when IP addresses get reused by different hosts.   I am probably more likely to encounter this than you because I build and test router firmware on a regular basis, but the principle is true in general.   If you think DNSSEC is a good idea, why aren't you getting your host key from DNSSEC?

---

From: Ted Lemon <[email-masked]>
Date: Sat, 29 Jul 2017 21:18:45 -0400

On Jul 29, 2017, at 8:15 PM, Randy Bush <[email-masked]> wrote:
> maybe kickstart with the nat64

I submitted a lot of tickets on nat64 in prague, but as far as I was able to tell they were all layer 1 propagation issues, not layer 3 issues.

If in fact there is a database of trouble report tickets that you think contains useful data, it would probably be a good idea to do something with that.  If we aren't doing that now, then as you say, there is not much point in making a V6-only+NAT64 network the default.

---

From: Randy Bush <[email-masked]>
Date: Sun, 30 Jul 2017 10:33:47 +0900

> I submitted a lot of tickets on nat64 in prague, but as far as I was
> able to tell they were all layer 1 propagation issues, not layer 3
> issues.

as ietf-nat64 is just yet another ssid on the same meeting area access
points as the other ssids (bar ietf-hotel), i doubt this is at all
unique to nat64 layer-1/2 propagation.

the only ietf99 ticket i can find from [email-masked] is
https://tickets.meeting.ietf.org/ticket/1138, which sounds to be what
you describe above.  asai san looked at it, responded, asked you to
retest, you did not respond, so the ticket was closed.

> If in fact there is a database of trouble report tickets that you
> think contains useful data, it would probably be a good idea to do
> something with that.

lucy, ietf noc ticket goddess, tried to copy all 99 nat64 tickets into a
bunch, see
https://tickets.meeting.ietf.org/query?status=accepted&status=assigned&status=closed&status=new&status=reopened&component=nat64&milestone=ietf-99&group=milestone&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority&report=10

collecting from < 99 could probably be done.  but no sense spending noc
volunteers' time on it until you're actually organized to actually do
something useful with the info.

randy

---

From: Ted Lemon <[email-masked]>
Date: Sat, 29 Jul 2017 21:34:53 -0400

Ok, I'll check it out.   Thanks for the pointer.

On Jul 29, 2017 9:33 PM, "Randy Bush" <[email-masked]> wrote:

> https://tickets.meeting.ietf.org/query?status=accepted&
> status=assigned&status=closed&status=new&status=reopened&
> component=nat64&milestone=ietf-99&group=milestone&col=
> id&col=summary&col=status&col=type&col=priority&col=
> milestone&col=component&order=priority&report=10
>

---

From: Randy Bush <[email-masked]>
Date: Sun, 30 Jul 2017 11:45:29 +0900

[ btw, the $subject is broken.  the ipv6only ssid is global ipv6 not
  nat64, which has its own ssid ]
 
> The IETF network is always going to have enough IPv4 addresses for
> every user.  Hence, it is _never_ going to be better for IETF users to
> use an IPv6-only network

as/if the global net becomes mostly v6, this will change.  or so we
hope.

> because the main feature of IPv6 is end-to-end

i suspect most folk believe the main feature is gaurab's dictum, "96
more bits, no magic."

and i suspect that ipv6 will be about as e2e as ipv4; maybe less so if
things such as nat64 are the transition rather than dual stack.  (yes,
dual stack is not realistic given 2^32 is a bit less than 2^128 or even
2^64 or whatever.  get in your time machine and tell that to the ipv6
architects back in 1990.)

> if you are still v4-privileged, you have end-to-end with v4, unlike
> the rest of the world.

perhaps have a look & listen to philipp's talk at irtfopen99
https://youtu.be/JRneMj7LX8U?list=PLC86T-6ZTP5jdbiwi5ggLNnwLn1-r0M4h&t=637
it's a cgn tragedy out there, especially in mobile which rules most of
the world.

it would be interesting to know/measure what proportion of connections
are actually e2e on v4 and v6.  and i am not interested in measures on
facebook, google, root servers, etc.  i am a backbone kinda guy.  the
ipv6 statistic that finally impressed me was when the seattle internet
exchange (about the 20th largest ix) crossed 10% ipv6 last month.

but what we can affect is what we do in the ietf.  and there are a whole
lot of our siblings deliberately breaking e2e.

randy

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 30 Jul 2017 07:36:23 +0200 (CEST)

> working transport.  how about a bug bounty?  and maybe a fix bounty a

There is nothing inherently broken with NAT64+DNS64+CLAT (or something 
like iOS has with bump-in-the-API).

Android has CLAT. iOS has its bump-in-the-API.

Win10 doesn't have any of this (the adviced CLAT is on WWAN only and 
mobile only). MacOS has bump-in-the-API for devices that use those APIs, 
which a lot doesn't. Anything uses the socket API doesn't get this. Linux 
doesn't have this out of the box afaik.

So there is nothing to be fixed for NAT64+DNS64, what needs to be fixed is 
that these operating systems need to support v4 literals through NAT64 by 
some kind of mechanism. Android does. iOS does. Nothing else does.

This is already well known. This "experiment" being proposed is in my mind 
useless because the outcome is already known. I connected a Win10 box to 
my NAT64+DNS64 experimental network two days ago to re-verify, and there 
were plenty of things that didn't work. Windows update doesn't think it's 
connected to the Internet. Steam won't even start.

Or is the objective of the experiment to have people from the operating 
system vendors discover that their operating systems has problems and that 
this discovery would make them fix these problems?

I emailed people at Microsoft about my 464XLAT findings. That resulted in 
me being told that the blog post would be updated and that a discussion 
would be had regarding that 464XLAT functionality perhaps coming to more 
generic use cases. I have already told people from Apples networking stack 
development team about my problems with NAT64+DNS64 and my VMs and also 
things using the socket API.

It seems a lot easier to just reach out to the OS vendors and tell them, 
than to try to use the painful detour of showing already known breakage on 
the IETF wifi for everybody to discover, most of who can do nothing about 
it.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 30 Jul 2017 09:45:38 +0200

So, looks like I’m not alone believing that instead of just NAT64+DNS64 what we actually need is what will solve the problem in the *real world*, which is CLAT in the LAN networks:

1) Having the IETF SSID with CLAT (as I’m suggesting that the “IPv6-only” CPEs – in the sense of IPv6-only-WAN, must support CLAT)
2) Having the hosts supporting CLAT as well, because bump-in-the-API doesn’t work for many apps that uses literals and don’t use the APIs. This is needed for tablets, laptops and cellular, because they can be used in a network behind a device offering tethering, otherwise 1 above will be enough.

And yes, in an ideal world, app developers/vendors will make sure to avoid using literals, and we don’t need to be the police+baby sitters, not counting the problem of old devices/apps that are no longer in the market and nobody will be able to take care of those. So again, best solution is 1+2.

Human nature has proven that we only reported 5-6 tickets, because human nature, when time is previous, during the meeting, will make that folks (including myself as my email wat not working on the NAT64 network), which detect a single “critical” failure (for them), move back to the dual-stack SSID (and only maybe report it).

I suggested having a small development to detect those apps automatically if we have a CLAT in the default SSID with the NAT64-DNS64. Yes, we will have no public IPv4 addresses, but at least we don’t break apps, so the people don’t need to move to the regular dual stack network (unless they need a public IP, which I’m not sure if it is common because in real-world you typically don’t have it). The next hackathon may be an opportunity to do that if we don’t find somebody before in the open source community to work on that. We may start with a simple VM with Jool, which is a powerful open source implementation for NAT64, SIIT, CLAT, etc. and have something that “increase” the log level to what we need. Even if it is not perfect, even if we only detect 20-30% of the broken apps (which will be all those using the CLAT, and I think will be more than this %, just being pessimistic), it will be much more than what we detect AND report “manually”.

We still have the issue of who takes the responsibility to inform the broken apps developers/vendors and track them to make sure it gets corrected …

Regards,
Jordi

---

From: Ted Lemon <[email-masked]>
Date: Sun, 30 Jul 2017 06:07:14 -0400

> lucy, ietf noc ticket goddess, tried to copy all 99 nat64 tickets into a

I read this as 99 tickets, but it’s only six. So not really a very substantial data set. :(

---

From: Tim Chown <[email-masked]>
Date: Sun, 30 Jul 2017 11:20:44 +0100

> On 30 Jul 2017, at 11:07, Ted Lemon <[email-masked]> wrote:
> 

6 tickets from how many users?

It’s great that Randy has pulled together the nat64-realted tickets.

Could we also run a short survey on the attendees list after the event, using the IETF survey monkey or whatever the meeting survey uses, on nat64 experiences for this who used it?

We could then for example use the NOC and survey data to keep a running I-D of issues that’s updated after each meeting?

Tim

---

From: Randy Bush <[email-masked]>
Date: Sun, 30 Jul 2017 19:25:57 +0900

>> lucy, ietf noc ticket goddess, tried to copy all 99 nat64 tickets
>> into a bunch, see

i view this as a good thing.  that is, an interop session or two, even
if they multiply it, might produce a list which could be cleared in some
months if y'all could motivate the vendors and app devs.

randy

---

From: Randy Bush <[email-masked]>
Date: Sun, 30 Jul 2017 19:35:04 +0900

> It’s great that Randy has pulled together the nat64-realted tickets.

lucy.  i said lucy.

randy

---

From: Tim Chown <[email-masked]>
Date: Sun, 30 Jul 2017 12:01:13 +0100

> On 30 Jul 2017, at 11:35, Randy Bush <[email-masked]> wrote:
> 

Apologies!  Thanks Lucy.

Tim

---

From: "Leddy, John" <[email-masked]>
Date: Sun, 30 Jul 2017 11:01:55 +0000

This is a very disheartening discussion from an Internet Service Provider and Enterprise perspective.

The IETF believes that the migration to IPV6 is critical to the future of the Internet.  (Yes?)
The IETF drives the standards and the resulting products that are available for deployment to solve Internet problems in the migration to IPV6.
The IETF is concerned that utilizing these technologies (even with an opt out V4 network) may impede its work at a conference.
The IETF is apprehensive that attendees may not have the skill/will to troubleshoot, work around or fix any resulting issues that could result.
The IETF concludes that these technologies are not ready for its own production use (“we have all the IPV4 space we need”) and need to be deployed by others (who do not have enough IPV4 space) to address gaps in the standards and resulting implementations.
The IETF believes the conferences are to do the NEW work of the IETF, not to be impacted by the quality of work it has already done.

I think you will find that neither Service Providers nor Enterprises believe that their business is deploying IPV6 technologies.
What should these organizations take away from this discussion?

Is the message really; Deploy IPV6 and risk your business?

John

    

    
    
    Tim

---

From: Lee Howard <[email-masked]>
Date: Sun, 30 Jul 2017 07:53:43 -0400

On 7/29/17, 1:55 PM, "ietf on behalf of Randy Bush" <[email-masked]

>working transport.  how about a bug bounty?  and maybe a fix bounty a

There are mulitple implementations of DNS64/NAT64. I think the one used by
the IETF NOC is from a router vendor, though I know of three router
vendors, at least one load balancer, and several open source
implementations (only one of which is intended for production use). I
haven’t tested them all, but I have no reason to think they are
particularly buggy.

Rather, I think the bugs are in applications.

How would default-NAT64 get application developers to fix their
applications? 

> tickets from {seoul,chicago,praha} if no other ideas come to mind.

I’m working on a research project along these lines, results of which I’ll
provide the IETF, and would be happy to help coordinate a NAT64 interop
testing project as part of IETF100-Singapore Hackathon.

Lee

---

From: Randy Bush <[email-masked]>
Date: Sun, 30 Jul 2017 21:55:02 +0900

> There are mulitple implementations of DNS64/NAT64. I think the one
> used by the IETF NOC is from a router vendor

a pair of donated A10s.  the noccers dealing with that stuff did not
want to call ietf-nat64 a suported production service until they got the
second one and could run it in redundant configuration.

> Rather, I think the bugs are in applications.

my guess is applications and the basic nature of nat64/dns64.  but it's
just a guess.

> I’m working on a research project along these lines, results of which
> I’ll provide the IETF, and would be happy to help coordinate a NAT64
> interop testing project as part of IETF100-Singapore Hackathon.

yay!  thank you.

randy

---

From: Ted Lemon <[email-masked]>
Date: Sun, 30 Jul 2017 09:25:15 -0400

> my guess is applications and the basic nature of nat64/dns64.  but it's

To applications, a NAT64 IPv4 host just looks like an IPv6 host.   The issues that come up tend to be either embedded IPv4 literals, or else cases where the app explicitly chooses which version of transport to use (e.g., OpenVPN used to do this).   Also, if you open a tunnel and start resolving domain names through that, you will start getting IPv4 addresses, and all your IPv4 connections will transit the tunnel, which may not be what you want. I think there are also issues that come up with L2TP, but I don't know the details.

The thing is, these issues are not random issues.   They show up or they don't.   They don't show up as flakiness: they show up as "it doesn't work at all."   So knowing how many out of an un-selected population actually run into these issues is pretty interesting.

That's why I want to make NAT64 the default.  But I suppose I am trying to write a check the NOC would have to cash.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 30 Jul 2017 09:27:17 -0400

> How would default-NAT64 get application developers to fix their

One of the biggest offenders historically was a Cisco VPN, so presumably having Cisco people experience that being borken would help.   Similarly with Microsoft people and the Windows Update issue that was mentioned earlier.   Desire to avoid public embarrassment is a useful motivating factor.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 30 Jul 2017 15:57:03 +0200

Not really so easy like that …

The reason I can’t use the NAT64 (unless I run my own CLAT VM, which requires the NOC to assign a /64 to my own laptop, as I did in the IETF98, or there is a CLAT in that network), is that Office is not working if the destinations are IPv4-only.

For example, I’ve email accounts that are IPv4-only. They don’t work. I’ve also one gmail email account, which is only a backup, I never use it. The gmail servers are dual-stack, so they work fine with Office for Mac.

I’m guessing that the Microsoft guys at the IETF use Microsoft OS (which already includes CLAT), so unless the failure is the same and fails as well in Microsoft OS with Office for windows, the Microsoft employees aren’t going to “suffer” the same pain as Mac OS users running Office for Mac.

So in my opinion, in a considerable %, this effort is useless.

The folks that are involved in deploying IPv6 in many networks worldwide (as it is my own case), we know without the need to try in the IETF network, that we can’t deploy IPv6-only in the LANs. We know that many apps/devices will not work if we do that. We know what is the real world, and we know that is a matter of time (probably more than 5 years) for ISPs to deliver IPv6-only WAN with IPv6-only LANs.

You can’t force customer to throw away their IP cameras, NAS, or all kind of old systems or business apps with IPv4-only support. Even if we tell the vendors, they will do it when they want, and all the products from vendors that don’t exists anymore will never be updated.

Regards,
Jordi

---

From: Bill Fenner <[email-masked]>
Date: Sun, 30 Jul 2017 10:44:33 -0400

Bill

> On Jul 30, 2017, at 9:27 AM, Ted Lemon <[email-masked]> wrote:
> 

On the other hand, the corporate VPN I use publishes a support matrix on their public web site, and specifically says that IPv6 is not supported. I don't think they're embarrassed about it.

Most people using VPNs will be in a weird state with NAT64 anyway, assuming that they use the VPN's DNS server (e.g., to access internal resources by name).  A split-tunnel VPN user will lose access to v4-only sites, since it will lose dns64 translation (and will simultaneously lose the ability to detect the nat64 via the rfc7050 lookup mechanism).  Does this mean "don't bother with split tunnel VPNs in a nat64 network"?

  Bill

---

From: Christian Huitema <[email-masked]>
Date: Sun, 30 Jul 2017 08:58:18 -0700

> like iOS has with bump-in-the-API). 

DNS64 assumes that the host uses the network provided DNS server, and
that it is OK to forge DNS replies. The first assumption is falsified
when the host uses another DNS server, such as provided by a VPN or by
DPRIVE. The second assumption is falsified when the host requires
DNSSEC. There are of course workarounds, which relies on some smart in
the host. And te whole point is to ensure that such workarounds are
deployed.

-- 
Christian Huitema

---

From: heasley <[email-masked]>
Date: Sun, 30 Jul 2017 16:09:30 +0000

> In other words, you want to opt everyone into doing your testing for you.

Wow, that is a toxic comment.  Vendors do not run EFT programs for fun.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 31 Jul 2017 08:09:40 +1200

> Most people using VPNs will be in a weird state with NAT64 anyway, assuming that they use the VPN's DNS server (e.g., to access internal resources by name).  A split-tunnel VPN user will lose acces…

So here's the thing. All NAT breaks stuff, therefore NAT64 breaks stuff.
In fact, it breaks stuff in more complex ways than NAT44 or even NAT444.

I see no good ending to the attempt to make NAT64 work in all circumstances.

     Brian

---

From: joel jaeggli <[email-masked]>
Date: Sun, 30 Jul 2017 14:49:37 +0200

On 7/29/17 20:17, Tim Chown wrote:

> 2. Whether we fully understand how devices of various common OSes
> select an SSID on startup, without manual intervention.
> 
> The line in Randy’s data that puzzled me was the 967 devices
> associating to the ietf-legacy99 SSID. I believe the SSID had the
> meeting number appended to avoid devices just re-associating to an
> ‘ietf-legacy’ SSID every meeting. By adding the number, one might
> hope users would have to manually select the SSID. But perhaps at
> least one major OS prefers this SSID because of its open property?

There's nothing paticularly odd about this.several of these operating
systems will both notify you opportunistically of available open
networks by default and make then visually distinctive. you then
condition a user population to select then becuase they are open, and
therefore don't require a cert, shared secret, username, password. and
you get a scenario where it's going to get selected between meetings.
unsurping since it's the low friction option.

We tested the steps associated with with associating with an open wifi
network on all the platforms we had available, and despite the
notification that security might be good idea, it is always the lowest
friction option.

---

From: "John Levine" <[email-masked]>
Date: 30 Jul 2017 23:06:30 -0000

In article <[email-masked]> you write:
>People who are forward-thinking (but not enough) in their use of DNSSEC and backward-thinking in their use of IPv6 will have problems.

Quite possibly, but so what.

If the IETF plans to treat what have historically been production
networks as experimental networks, please let us know so we can make
other plans, e.g., mifi from a local wireless carrier.

Even better, don't do that.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 30 Jul 2017 23:11:02 -0000

>working transport.  how about a bug bounty?  and maybe a fix bounty a

A bug bounty on ietf-v6only, perhaps spiffy tee-shirts, would be a dandy idea.

Forcing the whole conference to participate would not.

R's,
John

---

From: Randy Bush <[email-masked]>
Date: Mon, 31 Jul 2017 12:55:22 +0900

>> the question is how to progress fixing nat64/dns64, given that a lot
>> of folk come to ietf meetings to simply get work done and not debug a
>> semi- working transport.  how about a bug bounty?  and maybe a fix
>> bounty a few times larger!

someone suggested a tee shirt if you stayed on v6only and/or nat64 all
week.  and a further prize if you found a new solution to a common
problem on those networks.

someone else suggested that we turn off all other ssids for the 6man and
v6ops wg meetings.  there would be leakage, of course.  and it's a pita
(we *really* do not like to make changes during the week).  perhaps the
chairs could strongly encourage those in the wg meetings to use either
v6only or nat64.

> Forcing the whole conference to participate would not.

doh

my impression is that the noc, for which i do not speak, jim does, has
been strongly of the idea that the job is a network where people can get
their work done with absolutely minimal speedbumps.  tragically and, for
some of us, enragingly, v6only and nat64 do not meet that bar; dual
stack seems to.

[ btw, i should confess that, despite continuing efforts which have
  eaten a lot of my copious free time, i still do not have ipv6 in our
  tokyo apartment.  ntt-east (the carrier, not the internet provider)
  has worked quite hard to inhibit consumer ipv6 deployment in japan.
  ask lorenzo or erik for a more detailed rant than i can give.

  on bainbridge, john gives us great native ipv6 and nat44able ipv4.
  thank you, john.
  ]

randy

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 31 Jul 2017 08:10:11 +0200 (CEST)

> problem on those networks.

I could do this with my Android or iOS-device all week and feel no pain 
what so ever. It just works. That would be a lot of T-shirts.

However, if someone did this with their Windows or MacOS machine, that'd 
be a much bigger feat. I would personally buy $DRINK to whoever came up 
with a user-friendly installable CLAT solution for these OSes, and would 
whole-heartedly support giving T-shirts to people actually testing out 
this software all week, and reporting problems.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 31 Jul 2017 06:05:30 -0400

> Forcing the whole conference to participate would not.

I would just like to point out that nobody here has proposed forcing the whole conference to participate.   What the draft proposes is changing the _default_, not making non-NAT64 IPv4 service unavailable.

> chairs could strongly encourage those in the wg meetings to use either

I don't see the point.   We already know that NAT64 mostly works, and we know when it breaks, and why.   The only really interesting question is how many people this breakage affects, and what specific apps break.

> On Jul 30, 2017, at 10:44 AM, Bill Fenner <[email-masked]> wrote:

Would you be willing to share with us the name of the vendor?

---

From: Michael Richardson <[email-masked]>
Date: Mon, 31 Jul 2017 10:17:07 -0400

> chairs could strongly encourage those in the wg meetings to use either

I think that this is a really good idea.

I lived from v6ops onwards on nat64 during IETF99.
(But, my "VPN" has always used IPv6-only on the inside, so I never noticed
any loss)

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

---

From: Eric Gray <[email-masked]>
Date: Mon, 31 Jul 2017 14:25:16 +0000

Ted,

                This does not seem to be a good idea, because it makes things more difficult for most people so that it is easier for a few.  I rather like the idea that all of my devices are able to connect to the IETF WiFi by default.

If people want to avoid automatically connecting to SSID "ietf," it is not hard for them to cause their device(s) to "forget" that SSID.

And, if there is a particular reason why connecting to the default WiFi would be a problem at one IETF meeting, then we could change the SSID for that meeting only.

--
Eric

From: ietf [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Friday, July 28, 2017 6:22 PM
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: RESENDING - Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

On Jul 28, 2017, at 5:50 PM, Paul Hoffman <[email-masked]<mailto:[email-masked]>> wrote:
The legacy network will have a different SSID. All laptops remember which SSIDs you have connected to successfully in the past. Thus, it is likely that if you encounter problems and have to switch to the example-ssid-legacy SSID, and you close your laptop to move to a new room and open it again, you'll be put back onto the ietf SSID.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 31 Jul 2017 10:50:45 -0400

>                 This does not seem to be a good idea, because it makes things more difficult for most people so that it is easier for a few.  I rather like the idea that all of my devices are able…

This assertion is not based in fact, as far as I know.   The _fact_ is that we don't actually know whether this (v6-only+nat64 as the default) will create hardship for "most people".   It won't make it easier for anyone—that's not the point.

Also, none of your devices can connect to the IETF wifi automatically: it's protected by 802.1x, so you have to set that up, and in my experience doing so has not been trivial for some devices (e.g., my Chromebook and my Android).   I haven't had to introduce a new device to the IETF SSID in a while, but everybody who connects to the IETF SSID had to do something to connect to it—it didn't Just Happen.

FWIW, I don't think those folks who are reacting to this discussion negatively need to be so concerned.   As far as I can tell, the consensus on the mailing list is not to do this, and in particular if the NOC staff aren't willing to do it there's no point in us arguing about it.   I think the conversation has been useful, but if you feel the need to weigh in just to say you're against it, I think that need has passed.

I am disappointed with this apparent consensus, and surprised at and disappointed in some of the people who pushed back on the proposal.   But if you think I am continuing to participate in the conversation because I think I'm going to change the consensus, rest assured that I have no such illusions.

---

From: Tim Chown <[email-masked]>
Date: Mon, 31 Jul 2017 16:28:23 +0100

> On 31 Jul 2017, at 15:50, Ted Lemon <[email-masked]> wrote:
> 

This may be why 900+ devices associated to the ietf-legacy99 SSID automatically, even though they had not seen it before. I think Joel postulated about that previously.

> FWIW, I don't think those folks who are reacting to this discussion negatively need to be so concerned.   As far as I can tell, the consensus on the mailing list is not to do this, and in particula…

That is a pretty clear consensus.

Question is whether we can do more to help capture / share useful NAT64 usage data, or to feed into potential focused activity around a WG session or a hackathon event.

Tim

---

From: Adam Roach <[email-masked]>
Date: Mon, 31 Jul 2017 15:02:32 -0500

On 7/31/17 10:28 AM, Tim Chown wrote:
> Question is whether we can do more to help capture / share useful NAT64 usage data

I posit that there is room to do so in the way of education: if users 
better understood the purpose and nature of the nat64 network, and if 
there were some *non-technical* steering of people to try it out, 
parties interested in collecting such information would likely get more 
of the data they want. Today, users at IETF meetings are presented with 
a dazzling array of:

  * ietf
  * ietf-legacy
  * ietf-2.4ONLY
  * ietf-v6ONLY
  * ietf-hotel
  * ietf-nat64

...and I suspect most people have little clue about why most of these 
exist or which to use. The "nat64" variation certainly gets lost in the 
noise.

We've had "awareness" posters on-site to educate participants about BOFs 
occurring during the week for a while now; perhaps a similar poster 
explaining what the nat64 network is, that the NOC now considers it 
production-quality, why people might want to try it out, and how to 
report issues when they arise, would be useful in driving enough traffic 
to gather additional statistics. If you wanted to be even more 
aggressive about it, you could even replicate it on little slips of 
paper handed to people when they get their badges.

/a

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 1 Aug 2017 08:31:17 +1200

On 01/08/2017 02:17, Michael Richardson wrote:
>     > v6only or nat64.> 

It would have the advantage that more people would pay attention to the screen
and speaker rather than doing email. And also, more and more people would
become aware that nat64 breaks stuff. I suppose that's good too. As advertising
for IPv6, it would do rather badly.

    Brian

---

From: Ted Lemon <[email-masked]>
Date: Mon, 31 Jul 2017 16:46:22 -0400

On Jul 31, 2017, at 4:31 PM, Brian E Carpenter <[email-masked]> wrote:
> And also, more and more people would

Brian, why on earth would we want to advertise IPv6 to IETF attendees?   We invented IPv6.   If we really can't run a v6-only network at IETF, what that says is that we have failed utterly and expensively.   I do not believe that this is correct: IPv6 works very well.

The point of having NAT64 is that it lets us actually run without any IPv4 on the wire and see what happens.   If the only things that fail are things that go through NAT64, that's a good outcome, particularly if the number of things going through NAT64 that fail is small relative to the total number of things that go through it.

---

From: Ole Jacobsen <[email-masked]>
Date: Mon, 31 Jul 2017 14:00:33 -0700 (PDT)

You said:
> 
> Brian, why on earth would we want to advertise IPv6 to IETF 
> attendees?  We invented IPv6.  If we really can't run a v6-only 
> network at IETF, what that says is that we have failed utterly and 
> expensively.  I do not believe that this is correct: IPv6 works very 
> well.

Putting on my naive end-user hat:

That might be true, but here is the thing: "The mission of the IETF is 
to make the INTERNET work better..." (my emphasis)

For at least a decade now, I've been told that I should "just use 
IPv6" and some conferences have even "forced" me to do so.

I always respond with this question: "Does running IPv6 allow me to 
connect to the Internet?" (meaning the v4 Internet for the most part). 
The answer always seems to be: "Yes, but you have to manually 
configure this and, oh by the way, this won't work at all and that app 
might not behave as expected."

Demonstrating this to people who are experts seems like a waste
of time.

So it sounds to me like we HAVE indeed failed utterly and expensively. 
99% of Internet users do not have any idea what version of IP they are 
running just as they have no idea what a MAC address is or why/if they 
should care.

I'd love to see IPv6 succeed, but it is apparently impossible to do so 
without teaching end-users a lot of stuff they really have no interest 
in or ability to learn. What a shame.

Ole

---

From: Ted Lemon <[email-masked]>
Date: Mon, 31 Jul 2017 17:06:19 -0400

> in or ability to learn. What a shame.

This statement is why I think we need to be running IPv6 by default.   What you are saying here simply isn't true.   There are lots of internet users running IPv6 and not even aware that they are doing so.   This is very evident in the stats for service providers that offer their service over IPv6 as well as IPv4.

If you can't connect to the wire and start using it with no special settings, it's broken.   The point of having IETF people connecting to a v6-only wire is to see what problems they run into.   The answer should be "none," and at least for me at recent IETFs, _it has been_.   It would be nice to have a larger sample size.

The reason we are advocating this is not that we want you to debug the user interface.   It's that we think it works.

---

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

NAT64 was invented for a specific case (when apps use DNS and the right APIs).

We realized then that app/devices vendors are lazy, or just they are out of the market, so we invented 464XLAT, which uses the same concept as NAT64/DNS64, but improves it by using the CLAT, a small daemon code in the OS or the CPE to solve the problems of the literal addresses and non-APIs apps/devices.

We don’t need to tell the customers to disable IPv4 in their LANs, we need to make sure that we deploy CPEs that support CLAT. This way, users don’t need to throw away old devices or apps, neither learn anything about IPv4 or IPv6, and everybody is happy.

We are trying to solve a problem with NAT64 which we knew since it was invented that it can’t be solved. We don’t have the time (unless some magic is discovered) to now tell every ISP that is deploying IPv6 and NAT64, to instead of NAT64 have something different. The solution is there, if CPE vendors implement it, and we are talking about an available open source code (several implementations) that take a few bytes.

We are already doing this effort in v6ops, I started trying to tell the RFC7084 about the need to update it, but didn’t succeeded. It seems that now we may want to have instead of a CPE requirements including this, an additional document to be a must for CPE vendors to support it, in case the CPE expects “IPv4 old devices and apps” in the LANs (which is real world life, and will be for 3-5 years).

Regards,
Jordi

-----Mensaje original-----
De: ietf <[email-masked]> en nombre de Ole Jacobsen <[email-masked]>
Responder a: Ole Jacobsen <[email-masked]>
Fecha: lunes, 31 de julio de 2017, 23:01
Para: Ted Lemon <[email-masked]>
CC: <[email-masked]>
Asunto: Re: RESENDING - Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

    

    

    
    Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 1 Aug 2017 09:23:03 +1200

> Brian, why on earth would we want to advertise IPv6 to IETF attendees?   We invented IPv6.   If we really can't run a v6-only network at IETF, what that says is that we have failed utterly and expe…

Indeed it does. I use it whenever possible. Dual stack works very well, too.

> The point of having NAT64 is that it lets us actually run without any IPv4 on the wire and see what happens.   If the only things that fail are things that go through NAT64, that's a good outcome,…

There we differ. But then, I wrote RFC1671.

   Brian

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 31 Jul 2017 15:39:56 -0700

On 31 Jul 2017, at 14:06, Ted Lemon wrote:

> The reason we are advocating this is not that we want you to debug the 
> user interface.   It's that we think it works.

There's that "we" again. I'd like to hear from others in the operational 
community who agree with you, given that what I have heard from that 
community is that it "almost" works for technical users and "might not 
work" for typical users.

--Paul Hoffman

---

From: Bill Fenner <[email-masked]>
Date: Mon, 31 Jul 2017 18:40:00 -0400

On Mon, Jul 31, 2017 at 6:05 AM, Ted Lemon <[email-masked]> wrote:

> On the other hand, the corporate VPN I use publishes a support matrix on
> their public web site, and specifically says that IPv6 is not supported. I
> don't think they're embarrassed about it.
>
>

There's no reason to post it to this list specifically.  The ticket I filed
is in Lucy's list that Randy posted a link to; I also filed a ticket on the
noc ticket tracker in Seoul when there was a push to test nat64 at that
meeting.

Let's think like a VPN vendor, though: why not provide IP addresses of the
VPN server from the orchestrator to the client over the secure channel
you've already established, rather than allowing the client to perform DNS
lookups and perhaps succumb to an attack via that channel?  The thing
they're doing isn't dumb, it just doesn't work in a nat64 network.

  Bill

---

From: Ted Lemon <[email-masked]>
Date: Mon, 31 Jul 2017 20:27:56 -0400

I'm not the author of the draft, Paul. I just got involved in the
conversation because a lot of things were being said with which I disagree.
So "we" are the people who think this is a good idea, many of whom have a
great deal of operational experience.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 31 Jul 2017 20:29:30 -0400

Bill, you said they don't support IPv6. Did you mean they don't support
NAT64?

On Jul 31, 2017 6:40 PM, "Bill Fenner" <[email-masked]> wrote:

> There's no reason to post it to this list specifically.  The ticket I
> filed is in Lucy's list that Randy posted a link to; I also filed a ticket
> on the noc ticket tracker in Seoul when there was a push to test nat64 at
> that meeting.
>

---

From: Bill Fenner <[email-masked]>
Date: Mon, 31 Jul 2017 21:50:55 -0400

> Bill, you said they don't support IPv6. Did you mean they don't support

Perhaps I'm misreading the support matrix, but there's a list of versions
across the top and services across the side, and I think it says

Feature

IPv6 Support
  CoolOS X.0 CoolOS Y.0 CoolOS Z.0 CoolOS Z.1 CoolOS Q.0
SSL VPN No No No No No

And I take that to mean "in no version of CoolOS, including the
recently-released Q.0, is SSL VPN supported under IPv6".  And I think that
the CoolOS SSL VPN client needs to support IPv6 in order to work on an
IPv6-only network.

  Bill

>> Let's think like a VPN vendor, though: why not provide IP addresses of
>> the VPN server from the orchestrator to the client over the secure channel

---

From: Randy Bush <[email-masked]>
Date: Tue, 01 Aug 2017 11:10:10 +0900

Paul Hoffman wrote:
>> The reason we are advocating this is not that we want you to debug
>> the user interface.  It's that we think it works.
> There's that "we" again. I'd like to hear from others in the
> operational community who agree with you, given that what I have heard
> from that community is that it "almost" works for technical users and
> "might not work" for typical users.

i'm an operator who is fairly new to this ipv6 stuff; we only deployed
it commercially across our backbone (and through the cpe) in 1997.

in our meager experience, pure ipv6 with no hack to get to the ipv4
internet is not viable from the user perspective, period.  it won't be
for many years.  yes, this is a tragic failure; and we know where the
root causes lie.

nat64/dns64 is useful in constrained circumstances.  the ietf meeting
network is not one of them; as there is far too wide a variety of users,
some with laptops they can't even control due to IT departments, many
use vpns, applications are still incompatible, ...  this is yet another
tragedy.

the biggest obstacle to improvement on both these fronts is the denial
that there are serious problems, and hence far too little serious work
being done to ameliorate them.

but, no matter how hard we work, there is not going to be a magic day
when it all just works.  ipv6 is on-the-wire incompatible with ipv4;
so it is gonna be hacks; and hacks are tecnhnical debt.

randy

---

From: Alia Atlas <[email-masked]>
Date: Mon, 31 Jul 2017 23:22:06 -0400

Paul,

> community is that it "almost" works for technical users and "might not

The last Routing Area Working Group Chairs training/workshop, we had
information about the increasing deployment of
IPv6 - including to many many many consumers.  I haven't gotten the video
up quite yet - but this conversation is making
me prioritize it.  IPv6 growth is extremely significant.

It may be that there are some IETFers who run such special applications or
old software ( ascii art programs ;-) ) that we will
encounter different or additional issues. Granted, I didn't take advantage
of my ability to try out the IPv6 SSIDs made available
this past IETF - but this conversation is enough to convince not merely to
do so, but to consider printing out stickers - "I
upgraded to the modern Internet - with several checkboxes (IPv6, DNSsec
perhaps, etc.)."  I welcome inspiration there.

To claim that IPv6 just "almost works" for technical users is to ignore the
world outside our email lists.

Regards,
Alia

---

From: <[email-masked]>
Date: Tue, 1 Aug 2017 06:06:50 +0000

Hi Jordi,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : ietf [mailto:[email-masked]] De la part de JORDI PALET
> MARTINEZ
> Envoyé : lundi 31 juillet 2017 23:18
> À : [email-masked]
> Objet : Re: RESENDING - Incremental Deployment of IPv6-only Wi-Fi for IETF
> Meetings
> 

[Med] This may be misinterpreted as there is a dependency of NAT64 on DNS. This is not technically true. This was clarified in https://tools.ietf.org/html/rfc6889 

   This approach is pragmatic in the sense that there is no dependency
   on DNS implementation for the successful NAT handling.  As long as
   there is a function (e.g., DNS64 [RFC6147] or other means) that can
   construct an IPv6-embedded IPv4 address with a pre-configured IPv6
   prefix, an IPv4 address and a suffix (refer to [RFC6052]), NAT64 will
   work just fine.

FWIW, there are even NAT64 deployments that do not even rely on DNS64. 

> 
> We realized then that app/devices vendors are lazy, or just they are out
> of the market, so we invented 464XLAT, which uses the same concept as
> NAT64/DNS64, but improves it by using the CLAT, a small daemon code in the
> OS or the CPE to solve the problems of the literal addresses and non-APIs
> apps/devices.
> 
> We don’t need to tell the customers to disable IPv4 in their LANs, we need
> to make sure that we deploy CPEs that support CLAT.

[Med] Is there any CPE-based 464xlat deployment out there? 

 This way, users don’t
> need to throw away old devices or apps, neither learn anything about IPv4
> or IPv6, and everybody is happy.
> 
> We are trying to solve a problem with NAT64 which we knew since it was
> invented that it can’t be solved. We don’t have the time (unless some
> magic is discovered) to now tell every ISP that is deploying IPv6 and
> NAT64, to instead of NAT64 have something different.

[Med] These operators (with CPEs) are already doing something *different*: DS-Lite and the like. NAT64 is widely deployed in cellular networks (host-based model), which is really straightforward.   

 The solution is
> there, if CPE vendors implement it, and we are talking about an available
> open source code (several implementations) that take a few bytes.
> 
> We are already doing this effort in v6ops, I started trying to tell the
> RFC7084 about the need to update it, but didn’t succeeded. It seems that
> now we may want to have instead of a CPE requirements including this, an
> additional document to be a must for CPE vendors to support it, in case
> the CPE expects “IPv4 old devices and apps” in the LANs (which is real
> world life, and will be for 3-5 years).

[Med] I'm afraid we don't need it. The IETF already specified tools to address that case (DS-Lite, MAP-E).

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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 01 Aug 2017 08:52:10 +0200

Hi Med,

In line …

Saludos,
Jordi

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

    Hi Jordi,
    
    Please see inline. 
    
    Cheers,
    Med

[Jordi] Right, I was not pretending to be technically perfect, but introducing when NAT64 fails in our network.

[Jordi] Agree, we can talk about “DNS64 function” instead of DNS64. Again, in our IETF network there is a DNS64, so not the issue here.

 
[Jordi] I’ve identified 4 vendors up to now, with different products each. I’m sure there are more. I also know that other vendors did the development for specific customers and I’m also aware of other customers that asked for it. We have also the open source implementations, such as OpenWRT, supporting thousands of devices. Precisely this is my point. As IETF, our work is not just inventing transitions mechanism, but also making sure that if we state a set of requirements for CPEs, we include the support for those transition mechanisms.
   
     This way, users don’t

[Jordi] I agree, but if you have a network with cellular and wireline access, you may want to have a single transition mechanisms instead of two. If we don’t want to use NAT64 in wireline, then why we are trying to push it as the default SSID in our IETF network? It is a matter of preference of one or another transition mechanisms. All them have good and bad things. I see much simpler the combination of NAT64+CLAT than DS-Lite or MAP, in addition to the ONLY support in cellular networks is precisely NAT64/464XLAT, which means is the MOST extended transition mechanism by millions (billions?) of users. It makes a lot of sense to me to go in all the infrastructures to the one that has more deployment already.
   
     The solution is

[Jordi] I guess no need to repeat myself …