Re: IPv4 outage at next IETF in Chicago

Lee Howard <> Thu, 26 January 2017 16:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD8C1129863 for <>; Thu, 26 Jan 2017 08:12:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.252
X-Spam-Status: No, score=-1.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dTLrqsSXxFfU for <>; Thu, 26 Jan 2017 08:12:43 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 85E341297CE for <>; Thu, 26 Jan 2017 08:12:43 -0800 (PST)
Received: from ([]) by (8.14.4/8.14.4) with ESMTP id v0QGCfYb033421 for <>; Thu, 26 Jan 2017 11:12:42 -0500
Received: (qmail 14619 invoked by uid 0); 26 Jan 2017 16:12:41 -0000
Received: from unknown (HELO ? ( by 0 with ESMTPA; 26 Jan 2017 16:12:41 -0000
User-Agent: Microsoft-MacOutlook/
Date: Thu, 26 Jan 2017 11:12:38 -0500
Subject: Re: IPv4 outage at next IETF in Chicago
From: Lee Howard <>
To: Warren Kumari <>, Michal Krsek <>
Message-ID: <>
Thread-Topic: IPv4 outage at next IETF in Chicago
References: <> <> <158901d276b3$387d6050$a97820f0$> <> <WM!572ad9a6ae19416c99bd6357d98a5df59a81b46a887701f7fe5b0c3faf7d157d9ed99107720fab7bcb2711df4ea4ce8c!> <> <> <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Archived-At: <>
Cc: " Disgust" <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Jan 2017 16:12:45 -0000

>An IPv6-only SSID already exists -- it's even currently called
>"ietf-v6ONLY" (For users wanting pure IPv6 ).

I spend as much time as I can on that one, and have sent email to the NOC
about things that break. For me, Jabber was a key one that kept me from
staying there; I believe Google was unable to authenticate my Jabber
account over IPv6.
The unavailability of Github is another recurring problem, when so many
WGs store stuff there.

>There is also
>"ietf-nat64" (IPv6 stack with NAT64).

So I end up spending a lot of time on this one. Mostly works.

Question for you NOC folks: when I report a problem, how much information
do you need?
For instance, I can say, ³Jabber failed.²
Or I can say, ³Jabber failed, here¹s my account.²
Or I can say, ³Here¹s a packet capture of trying to log into Jabber.²
But I don¹t want to provide more data than is useful.

Also, I don¹t know of any reporting on tickets like that. That kind of
reporting would help us understand what still breaks on IPv6-only or
NAT64, and therefore how much pain it would be to make one of those
configurations be the default SSID. It would also help us focus pressure
on the apps and tools that break in such scenarios; if my Jabber problem
turns out to be authentication at Google, I could find somebody there who
might be able to help. Or if it¹s my client, I might be able to find (or
fund) the needed update.

Would you folks give us some guidance on how to report issues, and provide
some reports, so we can have metrics telling us when we can reasonably
make changes?

>This information is regularly
>communicated -- for example:
>Jim's email "[97all] IETF 97 Network Information ­ Seoul, South Korea"
>the IETF NOC reports - e.g: for IETF97 -
>, Slide 6 shows associations per SSID. 3 on ietf-v6ONLY and 19 on

Thanks for that pointer; these reports often go by too fast.
I find it fascinating that ietf-legacy is significantly more popular than
ietf. Why is that?

>As someone who's been involved in the NOC, I'm slightly irritated by
>the "You should really supply X, everyone wants it, how do I get this
>done?!" tone when it's been available (and not very widely used) for
>many years, and that a few seconds looking would have shown this.

Fair enough, and I understand the primary requirement for the IETF network
is to let people get their work done. So I¹m trying to figure out how to
list stuff that wouldn¹t work, so we can clear the way, so we don¹t
interfere with work.

Somebody earlier in the thread said something like, ³Let the IPv6 zealots
use IPv6.² We are. And we¹ve resolved what we can, and reported the rest.

>There has also been lots of previous discussion on this, for example:
>IETF 97 Plenary -
>7. IAB Open Mic Session
>"John Brzozowski referred to the IAB statement on IPv6, and suggested
>making the primary IETF SSID v6-only, perhaps with NAT64. One thing
>Comcast is working on is v6-only for end-user devices, supporting
>NAT64 and other implementations. They are seeing an increase in IPv6
>traffic and a decrease in IPv4 traffic. John Brzozowski said that it
>makes sense for the IETF community's primary SSID to outline a path
>forward for IPv6-only.
>Jari Arkko said that he would like to see some of this, and thinks
>that an incremental approach is what we need. Lee Howard asked how he
>would like the IAB to write tht plan. Jari Arkko replied that an
>Internet-Draft would work.

I think his actual words were more like, ³THat¹s one way to do it, but it
doesn¹t even have to be a draft.²

[more links elided, but thanks for them]