As a co-chair of the IETF v6ops Working Group, I thought I'd share my notes about yesterday's meeting with you, as actual operators, and ask for more input. Deprecating 6to4 Brian Carpenter discussed draft-ietf-v6ops-6to4-to-historic <http://tools.ietf.org/wg/v6ops/draft-ietf-v6ops-6to4-to-historic/> , specifically questions about whether to deprecate it completely, or just the version based on RFC3068 (which relies on anycast relays), and leave RFC3056 (useful for peer-to-peer kinds of connections) alone. That was the consensus. Relatedly, there was consensus to recommend filtering the anycast prefix 192.88.99.0/24, but not the related IPv6 version. Data Center Translation: SIIT-DC Tore Anderson presented (remotelyvery cool) his idea for statelessly translating from the IPv4 Internet to an IPv6-only data center. There was clear consensus that we should continue working on this as a working group, although it needs a better name, and Tore is looking for co-authors. If you have data center expertise and have ever wanted your name on an RFC, this is your chance. Read draft-anderson-v6ops-siit-dc <http://tools.ietf.org/id/draft-anderson-v6ops-siit-dc-01.txt> and draft-anderson-v6ops-siit-dc-2xlat <http://tools.ietf.org/id/draft-anderson-v6ops-siit-dc-2xlat-00.txt> and contact Tore. DHCPV6/SLAAC Interaction Bing Liu provided an update on two related documents, draft-ietf-v6ops-dhcpv6-slaac-problem <http://tools.ietf.org/wg/v6ops/draft-ietf-v6ops-dhcpv6-slaac-problem/> and draft-liu-v6ops-dhcpv6-slaac-guidance <http://tools.ietf.org/id/draft-liu-v6ops-dhcpv6-slaac-guidance-03.txt> . The discussion focussed on whether the behavior in the presence of both DHCPv6 and SLAAC is simply ambiguous (and therefore dependent on implementation) or broken. If it's ambiguous, we can clarify. If it's broken, we probably need a specification update (and, in fact, the DHC working group is working on revising rfc3315). We determined that the Problem Statement document (which may need to be renamed) should focus on behaviors in real implementations, and come back to the Guidance document later. Considerations for Using ULAs Bing also updated us on draft-ietf-v6ops-ula-usage-recommendations <http://tools.ietf.org/wg/v6ops/draft-ietf-v6ops-ula-usage-recommendations/> , but there was little discussion other than making sure it was consistent with current work in the Homenet WG. Considerations for Running Multiple IPv6 Prefixes Sheng Jiang updated us on draft-liu-v6ops-running-multiple-prefixes <http://tools.ietf.org/id/draft-liu-v6ops-running-multiple-prefixes-02.txt> , but it wasn't clear how useful it will be given ongoing work in the MIF WG, and whether NAT/NPT uses were relevant. We may revisit it later, if people want further discussion. IPv6 Vulnerability Test Program in Japan Ruri Hiromi described the IPv6 vulnerability test program in Japan <https://tools.ietf.org/html/draft-jpcert-ipv6vullnerability-check> , and asked for more participation and support. This has the potential for being very useful work; check it out. IPv6 Extension Headers Fernando Gont detailed his ongoing work on IPv6 Extension Headers in the Real World <https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world> . The authors found that packets with IPv6 EH are often dropped: 20% drop rate for fragments 10% drops for Destination Options 40% drops for Hop-by-Hop options 25% for fragmented traffic 20-60% of drops occur at an AS other than Destination AS There was general agreement that this was bad, and he described several ramifications, including DOS vulnerabilities. Fernando said that applications relying on EH will need a fallback mechanism, but there was consensus that dropping EH packets is the problem, not the protocol design. We may work on a document providing recommendations on how to configure. This seems like a great topic for NANOG members to chime in on; do you drop packets with Extension Headers, and if so, why? Design Choices for IPv6 Networks Victor Kuarsingh presented Design Choices for IPv6 Networks <https://tools.ietf.org/html/draft-ietf-v6ops-design-choices> , and got consensus that the title and abstract needed a tighter scope, and the document should mention a couple of other design alternatives that are documented in other internet-drafts and RFCs. This document would also greatly benefit from review from NANOG participants, as it is intended for this audience. IPv4 Literals Break in NAT64 Osamu proposed A Special Purpose TLD to resolve IPv4 Address Literal on DNS64/NAT64 environments <https://tools.ietf.org/html/draft-osamu-v6ops-ipv4-literal-in-url> . There was good discussion, but not consensus that this was the right solution. Considerations on IPv6-only DNS Development Linjiang Song talked about Considerations on IPv6-only DNS Development <https://tools.ietf.org/html/draft-song-sunset4-ipv6only-dns> . Discussion focussed on the need for support for EDNS0, especially in Android. IPv6 Considerations for NFV Hui Deng described IPv6 Considerations for Network Function Virtualization (NFV) <https://tools.ietf.org/html/draft-chen-v6ops-nfv-ipv6> , which was enlightening for people like me who have not been deeply involved in OpenStack or NFV generally. There is a lot of work needed to get good IPv6 networking support. There are several other internet drafts related to OpenStack: go to https://datatracker.ietf.org/doc <https://datatracker.ietf.org/doc> / and search for "openstack." If any of these topics look interesting to you, there are a couple of things you can and should do: 1. Subscribe to the v6ops mailing list: https://www.ietf.org/mailman/listinfo/v6ops 2. Read the full draft, and send comments and questions to the v6ops mailing list Please note that if you reply here, some people will see your comments: if you do not clearly intend your statements not to be IETF Contributions, they may be considered as suchin other words, read the Note Well <https://www.ietf.org/about/note-well.html> . I hope this summary is interesting and useful. I would really like to see more operator input to our work. Thanks, Lee