ietf
[Top] [All Lists]

Re: IPv4 outage at next IETF in Chicago

2017-01-26 10:12:59


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 -
https://www.ietf.org/proceedings/97/slides/slides-97-ietf-sessa-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.

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 -
https://www.ietf.org/proceedings/97/minutes/minutes-97-ietf-00.html

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]
?

Lee