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,