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