Re: IPv4 outage at next IETF in Chicago

John C Klensin <> Thu, 26 January 2017 17:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A21E21298AA for <>; Thu, 26 Jan 2017 09:08:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.098
X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6Vlv1rc2PxVc for <>; Thu, 26 Jan 2017 09:08:22 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E74D812989E for <>; Thu, 26 Jan 2017 09:08:21 -0800 (PST)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1cWnX2-000JAA-Gk; Thu, 26 Jan 2017 12:08:20 -0500
Date: Thu, 26 Jan 2017 12:08:14 -0500
From: John C Klensin <>
To: Lee Howard <>
Subject: Re: IPv4 outage at next IETF in Chicago
Message-ID: <54CA64795300BE3B39625CD4@PSB>
In-Reply-To: <>
References: <> <> <158901d276b3$387d6050$a97820f0$> <> <WM!572ad9a6ae19416c99bd6357d98a5df59a81b46a887701f7fe5b0c3faf7d1 57d9ed99107720fab7bcb2711df4ea4ce8c!> <1350087674.115436952.1485371218219.JavaMail.zimbra@peachymango.o rg> <> <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
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 17:08:23 -0000


This strongly suggests that it would be a good idea for the NOC
to have a web-based reporting form that specifically asks for
(or, when possible, automagically fills in) whatever information
is needed to cause a ticket to make sense and be useful.  I'd
hate to see such a thing replace the email options -- if nothing
else, if one is trying to work around a problem but still report
it, it may be faster to get an email message out and that speed
may make the difference between a useful "something is wrong'
heads-up report and silence -- but the odds of many of us
spontaneously remembering a list of things that should be
included in a report are not very high.


--On Thursday, January 26, 2017 11:12 -0500 Lee Howard
<> wrote:

>> 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 -
>> sa-noc-report -00.pdf
>> , Slide 6 shows associations per SSID. 3 on ietf-v6ONLY and
>> 19 on ietf-nat64.
> 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.