Subject: [100attendees] further on nat64

From: Randy Bush <[email-masked]>
Date: Sat, 11 Nov 2017 05:48:05 +0800

as jim mentioned, we strongly encourage you to try nat64; and *please*
report any issues, including technical details.

starting in eoul, the v6 folk pushed for nat64 to be the ssid of choice,
but there was a lot of 'i just want to get my work done' push-back; and
the noc runs the network so you can get your work done.  but we would
really like to make nat64 usable.  so ...

two further efforts are in play

  with the support of the wg chairs, the 6man and v6ops wg meetings will
  have non-ipv6 ssids turned off on their access points.  it's dog food
  time, folk.  please use them and do not use the dual-stack and other
  ssids which bleed over from your neighboring rooms; you will overload
  them.

  jen linkova, with the support of the noc, is running a nat64 interop
  in the hackathon.  thanks to hacking by joe clarke, bill fenner, and
  clemens schrimpe, there will be two special ssids in the hackathon,
  one nat64 and one dual stack.  they go through s switch where we can
  tcpdump to debug (warning: your data may be captured).  please try all
  the applications and networking tools you need to get your work done
  on the nat64 ssid.  if you have a problem, tell us so we can tcpdump
  it.  then try the dual stack so we can capture what should have
  happened.  the data will be taken home and analysed and we'll report
  back.  big thanks to jen linkova and the noccers for putting this
  seemingly simple experiment together.

[ and thanks to comcast for the a10s so the noc has redundancy to field
  a reliable nat64 network ]

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Nov 2017 15:05:39 +1300

> report any issues, including technical details.

FYI, I hooked onto ietf-nat64 on Sunday and stayed with it all
week. There are tickets for the minor issues I noticed; and I
only noticed them because I provoked the tools I suspected would
exhibit IPv4-only behaviour. I did all my work with no problems
(including SSH back to an IPv4-only server in NZ, which worked
perfectly, to my amazement).

IOW the dogfood was yummy.

    Brian

---

From: Chris Morrow <[email-masked]>
Date: Fri, 17 Nov 2017 02:31:12 +0000

> IOW the dogfood was yummy.
since connecting to any other SSID was "hard" ... I just did everything
from nat64 as well.
I almost use exclusively:
   http(s)
   ssh

so... it all 'just worked' for me as well. Thanks to our http overlords
everything does http(s) and nst64 is much less scary!
-chris
(thanks noc-en-folken!)

---

From: Lee Howard <[email-masked]>
Date: Fri, 17 Nov 2017 11:52:59 +0800

I want to thank you all for doing this.
It wasn’t flawless at all times, but it was educational. I see lots of
tickets have been opened, and I would love to see a summary of the issues
if someone can spare the effort. I tried to browse tickets at
https://tickets.meeting.ietf.org/wiki/nat64 but the links are malformed
(click one to see).
Due to the number of tickets, I wouldn’t push for NAT64 to be default yet,
but I would welcome repeating the experiment, and expanding it until the
number of tickets is comparable to the current default SSID.

Lee

On 11/10/17, 4:48 PM, "100attendees on behalf of Randy Bush"
<[email-masked] on behalf of [email-masked]> wrote:

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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 17 Nov 2017 12:10:02 +0800

I think, now that we decided to do those experiments in our working network, next time we should try instead or in addition to NAT64, a CLAT SSID.

Regards,
Jordi

-----Mensaje original-----
De: 100attendees <[email-masked]> en nombre de Lee Howard <[email-masked]>
Responder a: <[email-masked]>
Fecha: viernes, 17 de noviembre de 2017, 12:01
Para: Randy Bush <[email-masked]>, Jim Martin <[email-masked]>
CC: <[email-masked]>
Asunto: Re: [100attendees] further on nat64

    Lee

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

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Bill Fenner <[email-masked]>
Date: Thu, 16 Nov 2017 23:13:15 -0500

On Thu, Nov 16, 2017 at 10:52 PM, Lee Howard <[email-masked]> wrote:

> I tried to browse tickets at

The first 5 or so links were malformed with an extra '#'. I've fixed the
ones that I could find; please browse again.

  Bill

---

From: Alexandre PETRESCU <[email-masked]>
Date: Fri, 17 Nov 2017 05:34:20 +0100

> perfectly, to my amazement).

Brian, browsing the web interface of my in-home IPv4-only web server did 
not work.  The developer of that interface only provides an IPv4 address 
to connect to, not an FQDN.  Maybe I will open a ticket with them. (it's 
free.fr).

ping 8.8.8.8 did not work either, and that's unfixable.  It can even be 
used by end-user as a test.  Combined with results of ping6 
ipv6.google.com it can tell on what kind of network one is (v4 only, 
v6-only, nat64, etc.).

skype test call does not work.  Skype is an essential tool for me while 
at IETF meetings, even though I am forbidden to use it while in office, 
for security policy.

Some webex did work on "ietf-v6ONLY" but some not.  (yesterday during 
the 5gangip side meeting the webex on "ietf-v6ONLY" did not work, the 
URL was starting with t-systems.webex.com).   We did not try it on 
"ietf-nat64" yesterday.  I am willing to try with others many kinds of 
webex, lync, skype, skype enterprise, hangouts, coop'net, arkadin.

Alex

---

From: "Ole Troan (otroan)" <[email-masked]>
Date: Fri, 17 Nov 2017 06:07:32 +0000

> On 17 Nov 2017, at 05:34, Alexandre PETRESCU <[email-masked]> wrote:
> 
> ping 8.8.8.8 did not work either, and that's unfixable.  It can even be used by end-user as a test.  Combined with results of ping6 ipv6.google.com it can tell on what kind of network one is (v4 only, v6-only, nat64, etc.).

That’s a feature. 
Try ping6 64:ff9b::8.8.8.8

Ole

---

From: "Ole Troan (otroan)" <[email-masked]>
Date: Fri, 17 Nov 2017 06:09:32 +0000

Jordi,

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

To achieve what exactly ?
The “ietf” SSID is already dual stack. 

Ole

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 17 Nov 2017 14:26:09 +0800

If the intend of NAT64, as I understood is to try our own dogfood, let’s try the real one, or both in different SSIDs.

What the market will demand in a short term, is dual stack with IPv6-only access links.

The market for IPv6-only in the LANs will come later.

Regards,
Jordi

-----Mensaje original-----
De: "Ole Troan (otroan)" <[email-masked]>
Responder a: <[email-masked]>
Fecha: viernes, 17 de noviembre de 2017, 14:09
Para: "[email-masked]" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: Re: [100attendees] further on nat64

    Jordi,

    
    Ole

---

From: Alexandre PETRESCU <[email-masked]>
Date: Fri, 17 Nov 2017 07:59:12 +0100

> Try ping6 64:ff9b::8.8.8.8

Ah the ESSID is silent now... can't check.

But I guess you meant ping6 -n, because there may be reverse resolution 
error problems otherwise(?).

I mean, 64:ff9b::8.8.8.8 resolves inversely ok while here at IETF, but 
if I try to resolve it inversely elsewhere - will it work?

For example, 64:ff9b::8.8.8.8 does resolve inversely ok, if nslookup 
while here on 'ietf-hotel'.
But it does not resolve inversely at the publicly available inverse 
resolver mxtoolbox.com.
The respective IPv6 address, which I call 'true address', 
2001:4860:4860::8888 resolves ok in many places, including at mxtoolbox.

ping6 uses inverse resolution to display the replies, unless one says '-n'.

Alex

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 17 Nov 2017 10:07:08 +0000

> It wasn’t flawless at all times, but it was educational. I see lots of tickets have
> been opened, and I would love to see a summary of the issues if someone
> can spare the effort. I tried to browse tickets at
> https://tickets.meeting.ietf.org/wiki/nat64  but the links are
> malformed (click one to see).

Hi Lee,
If you do choose to repeat the experiment in the same manner (by forcing use of v6-only or nat64 during v6ops), you'll need to find someone else to take minutes. It was incredibly painful on Monday. I couldn't run my out-dated jabber client to get the names of speakers Mikael was posting. No matter which SSID I connected to, I kept getting dropped. I ended up giving up on Etherpad halfway through and taking minutes using notepad. Then I watched the video to recover minutes I lost because of getting repeatedly dropped from Etherpad during the first half. I didn't do any tickets because I was too busy trying to take minutes and deal with all the connectivity issues, and didn't have time to diagnose. It was all just seriously miserable. 
Barbara

---

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

My principal comment is - thanks for taking minutes!

> On Nov 17, 2017, at 6:07 PM, STARK, BARBARA H <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Nov 2017 23:50:52 +1300

> My principal comment is - thanks for taking minutes!

+1 to that.

The gajim jabber client was fine all week, and I assume the
meetecho jabber pane was working since nobody has complained.
But there seems to be a serious epidemic of software rot among
jabber clients.

   Brian

---

From: Lee Howard <[email-masked]>
Date: Fri, 17 Nov 2017 22:19:31 +0800

On 11/17/17, 6:07 PM, "100attendees on behalf of STARK, BARBARA H"
<[email-masked] on behalf of [email-masked]> wrote:

>>tickets have
>If you do choose to repeat the experiment in the same manner (by forcing
>use of v6-only or nat64 during v6ops), you'll need to find someone else
>to take minutes. It was incredibly painful on Monday. I couldn't run my
>out-dated jabber client to get the names of speakers Mikael was posting.
>No matter which SSID I connected to, I kept getting dropped. I ended up
>giving up on Etherpad halfway through and taking minutes using notepad.
>Then I watched the video to recover minutes I lost because of getting
>repeatedly dropped from Etherpad during the first half. I didn't do any
>tickets because I was too busy trying to take minutes and deal with all
>the connectivity issues, and didn't have time to diagnose. It was all
>just seriously miserable.
>Barbara

Ugh, I had no idea it sucked for you so badly. Thank you so much for
taking minutes for us!

Lee

---

From: John C Klensin <[email-masked]>
Date: Fri, 17 Nov 2017 11:26:20 -0500

--On Friday, November 17, 2017 23:50 +1300 Brian E Carpenter
<[email-masked]> wrote:

>...

The Meetecho pane was, indeed, working as well as it ever has.
But, at least when I'm coming in remotely, I often want to look
at that Meetecho pane and the participant list at the same time,
or to get the slides or other display of what is going on
in-room as large as possible.   Either the large slide or video
display or showing the participant list causes the Jabber panel
to vanish or become so small as to be useless.

In prior meetings, my solution has been to run a standalone
Jabber client and just ignore the Meetecho pane, but that caused
its own issues, including having two of me on Jabber -- one the
standalone login and the other the meetecho one that I get
automatically when I turn "Participant" mode on.   So still some
rough edges.

I reported these things before, so I didn't bother with tickets
this time.  

However, this time, the Jabber (and other things) client I've
been using for years froze up and became unusable, so that
solution was not possible.  So I have to agree about the
epidemic of software rot.

     john

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 18 Nov 2017 05:54:32 +0800

Regarding Jabber clients, Adium works well for me on a Mac. The Windows
equivalent is Pidgin, but I don’t have personal experience with it.

Cheers,
Andy

---

From: Jen Linkova <[email-masked]>
Date: Sun, 19 Nov 2017 01:49:35 +1100

> If you do choose to repeat the experiment in the same manner (by forcing use of v6-only or nat64 during v6ops), you'll need to find someone else to take minutes. It was incredibly painful on Monday…

;( I'm sorry to hear that, I did not know it was so bad for you.
It *might* be that you observed an ongoing network issue which was
mitigated later on Wed.
I did test Etherpad and Adium during the hackathon and did not see any problems.
What OS/Jabber client were you using?

-- 
SY, Jen Linkova aka Furry

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 20 Nov 2017 12:28:07 +0000

> > I didn't do any tickets because I
> > was too busy trying to take minutes and deal with all the connectivity issues,
> > and didn't have time to diagnose. It was all just seriously miserable.

> It *might* be that you observed an ongoing network issue which was

That could be. The experience on Thursday was definitely better. Though on Thursday, I also decided to use my corporate laptop (with powerful dual band AC Wi-Fi adaptor), instead of my personal laptop with under-powered 2.4-only b/g/n Wi-Fi adaptor. I'm not allowed to load a jabber client on my corporate laptop -- but decided Thursday just to follow the jabber log instead of logging in to a client. I also noticed that when Mark Townsley got up and walked away from his seat on Monday my connectivity improved a bit. It got bad when he sat down again. This *could* just be coincidence.

> I did test Etherpad and Adium during the hackathon and did not see any

The problem was not with Etherpad directly. The problem was with connectivity to Etherpad going up and down. There is delay between when connectivity is lost and loss of connectivity is recognized (so you can't type anymore). Everything typed during this delay is lost. 

> What OS/Jabber client were you using?

Psi

Barbara

---

From: Keith Mitchell <[email-masked]>
Date: Mon, 20 Nov 2017 09:19:19 -0500

On 11/20/2017 07:28 AM, STARK, BARBARA H wrote:
>>> I didn't do any tickets because I was too busy trying to take 
>>> minutes and deal with all the connectivity issues,

> That could be. The experience on Thursday was definitely better. 
> Though on Thursday, I also decided to use my corporate laptop (with 
> powerful dual band AC Wi-Fi adaptor), instead of my personal laptop 
> with under-powered 2.4-only b/g/n Wi-Fi adaptor.

> The problem was not with Etherpad directly. The problem was with 
> connectivity to Etherpad going up and down.

FWIW, I experienced this too. About 10-20 minutes after associating on
the "ietf" SSID, it would de-associate me. I didn't report it to the NOC
because I thought it was an issue with my exotic first-time-out client
(SUSE Tumbleweed Linux on an aarch64 Chromebook, mwifiex 802.11ac
driver) that I didn't see with my more regular x86_64 other laptop.
Getting it to re-associate was fairly non-deterministic, but at least
needed me to rfkill the interface off and on again. I left end Wed, but
have not however seen this issue with the aarch64 client and any other
WiFi network.

Hope that data point is helpful if somewhat after the fact.

Keith

---

From: Yoav Nir <[email-masked]>
Date: Mon, 20 Nov 2017 18:20:15 +0200

> On 20 Nov 2017, at 14:28, STARK, BARBARA H <[email-masked]> wrote:
> 

FWIW I experienced connectivity issues with Etherpad on the regular ietf (not nat64) network, but not with Jabber.  So Etherpad may be a separate problem.

>> What OS/Jabber client were you using?

Same here and I had no problems on the ietf network.

Yoav

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 20 Nov 2017 16:39:08 +0000

> connectivity to Etherpad going up and down. There is delay between when
> connectivity is lost and loss of connectivity is recognized (so you can't type
> anymore). Everything typed during this delay is lost.
> 
> FWIW I experienced connectivity issues with Etherpad on the regular ietf
> (not nat64) network, but not with Jabber.  So Etherpad may be a separate
> problem.

Yes. Etherpad issue was most likely Wi-Fi connectivity that was unstable. Even on Thursday I experienced some Etherpad connectivity instability, so it wasn't just Monday morning jitters. But the frequency of up-down on Monday morning was rather extreme.

> Same here and I had no problems on the ietf network.

v6ops was doing an "eat your own dogfood" experiment Monday morning during its session. They disabled broadcast of ietf SSID in that room, trying to force people to use either the v6-only or nat64 SSIDs. Thus my specific displeasure at trying to take v6ops minutes while eating dogfood that tasted nothing like proper people-food.

Barbara

---

From: Alexandre PETRESCU <[email-masked]>
Date: Mon, 20 Nov 2017 17:48:45 +0100

--
Alexandre Petrescu
[email-masked], tél 0169089223

> FWIW I experienced connectivity issues with Etherpad on the regular ietf (not nat64) network, but not with Jabber.  So Etherpad may be a separate problem.

I agree there are separate problems that relate to the WiFi deployment 
only, regardless of IPv6 vs IPv4.

For example, the "ietf-legacy" SSID has been very unstable in large 
meeting rooms (e.g. v6ops, plenary) vs small meeting rooms.  And that 
was so since it was invented a few IETFs back.  On "ietf-legacy" my VPN 
was up alive for no more than 5 minutes or so in large meeting rooms, 
but it was up alive during the entire meeting if the meeting room was small.

That 'legacy' word has nothing to do with IPv4 or IPv6, but it is about 
the authentication scheme and the frequency band.

There were other problems as well.

Alex

---

From: joel jaeggli <[email-masked]>
Date: Mon, 20 Nov 2017 10:07:27 -0800

> the authentication scheme and the frequency band.

The legacy ssid is delivered on the same radios and frequency bands as
the other mixed 2.4 and 5ghz ssids. legacy is not encrypted so it's not
clear what you mean by authentication scheme. legacy is intended to have
largely identical behavior to ietf prior to that having wpa2 enterprise
enabled.

ietf ietf-v6ONLY ietf-nat64 were 5ghz only.

---

From: Alexandre PETRESCU <[email-masked]>
Date: Mon, 20 Nov 2017 19:45:34 +0100

Le 20/11/2017 à 19:07, joel jaeggli a écrit :
> clear what you mean by authentication scheme.

That's what I meant - no encryption.

>   legacy is intended to have

YEs.

As we discussed separately, that wpa2 enterprise constituted a big 
problem for my laptop.

Alex