IPv6 Operations

Wed Nov 12 02:02:37 UTC 2014

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 (remotely‹very 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 such‹in 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