Skip to main content

Minutes for V6OPS at IETF-91
minutes-91-v6ops-1

Meeting Minutes IPv6 Operations (v6ops) WG
Date and time 2014-11-10 19:00
Title Minutes for V6OPS at IETF-91
State Active
Other versions plain text
Last updated 2014-11-14

minutes-91-v6ops-1
IPv6 Operations Ð IETF91
Monday, 10 November 2014

Deprecating Connection of IPv6 Domains via IPv4 Clouds (6to4)
Brian Carpenter
Proposed as BCP, 6to4 NOT RECOMMENDED in product support, MUST disable by
default, SHOULD consider dropping 6to4 relay servers, p2p 6to4 (not depending
on anycast) might still be okay Dave Thaler: If we deprecate 6to4, Teredo is
next in line in policy table.  Opposite of what we want.  Thus, do not
deprecate rfc3056 (p2p mode) without also deprecating Teredo. But Xbox uses
Teredo for p2p, so canÕt deprecate it yet. Lorenzo Collitti: We must show harm
to deprecate p2p mode (3056). We canÕt show harm, so we shouldnÕt deprecate.
Cameron: I null route 6to4 prefixes, especially 192.88.99.0/24 so it doesnÕt
create half-open CGN state.  Maybe need a sunset4 draft saying weird IPv4
brokenness like this will pop up. Michael Richardson: deprecate rfc3068 only,
too much risk in deprecating p2p James Woodyatt: agree.  Also agree that
content providers should (instead of may) keep return relays running. Maybe
also NAT64 ops should do. Yourtchenko: Yes, filter 192.88.99.0/24 Abramsson:
DonÕt spend brain cycles on new relays Hums: Should we deprecate 3068?  YES:
Strong hum. Should we deprecate 3056?  YES: Hum, NO: slightly stronger hum
Should we recommend filtering 192.88.99.0/24?  YES: Weak hum.  NO: Very weak
hum Should we recommend filtering 2002::/16?  YES: One hum Outcome: Revise
draft accordingly, then WGLC

SIIT-DC
Tore Anderson, remote
Needs a better name than ÒSIIT-DCÓ
Needs co-authors
Yourtchenko: Could also do CLAT function as bump in the API
Cameron would use this, may review but couldnÕt co-author
Thaler: This isnÕt a new protocol, just good use cases.  Prefer the name
ÒStateless NAT64Ó.    Clarify rationale for static mapping.  Still need a
better name. Adopt both SIIT drafts as WG? YES: Strong hum Call it stateless
NAT64? Weak hum
      SIIT-DC?  Quiet
        Other? Quiet
Outcome: repost as draft-ietf-v6ops-siit-dc and draft-ietf-v6ops-siit-dc-2xlat.
        Cameron Byrne to review

DHCPV6/SLAAC Interaction
Bing Liu
Bernie Volz: DHC WG is working on 3315-bis. (Revising dhcpv6)
Lorenzo Collitti: There is no problem, just different implementations.  The
problem statement draft can just document what implementations do.  Document
undocumented-unspecified behaviors.  DonÕt call it a problem statement; add
more testing and give it to operators documenting these corner cases.  DonÕt
think we should adopt ÐGuidance, until/unless we see real operational problems.
Fred: So should the Guidance draft go to DHC to inform their update? Brian
Carpenter: Disagree with everything Lorenzo said.  6renum noted that changing
mechanisms really breaks stuff.  Stall on ÐGuidance doc.  DHC should look at
it, to make sure they donÕt make anything worse, need 6man to fix what exists
now. Yourtchenko: For some of the inconsistent behaviors, we donÕt know what
the ÒrightÓ behavior is. Lorenzo Collitti: If we do what Brian says, 6man will
say, ÒWe deprecated M and O.Ó Ole Troan: If someone proposed a solution, we
would listen to it. Barbara Stark: The ambiguity exists; document the ambiguous
behavior. If you want to make it less ambiguous, go to 6man. Suresh
Ramasubramanian: See rfc4861 and rfc4862 Summary: DHCPv6/SLAAC problem
statement: Focus on behaviors in real implementations (and maybe rename it).
Outcome:  Adopt ÐGuidance as WG doc?  YES: Silence, NO: weak hum

Considerations For Using Unique Local Addresses
Bing Liu
Brian Carpenter: Is this consistent with what Homenet is saying?
Bing: Yes, currently compatible

Considerations for Running Multiple IPv6 Prefixes
Sheng Jiang
Erik Kline: Strike all text about IPv6 NAT
Mikael Abrahamsson: work in progress at MIF, but not sure we need to say it
Lorenzo Collitti: Security isnÕt unique to multiple prefixes. Specifically,
letÕs not put a lot of text saying Òmultiple prefixes will exhaust ND cache,Ó
when hosts give multiple addresses anyway.  Take the text out, and put it in a
new document.  Maybe not call attention to LLA as multiple prefixes.  But if
you take that out, youÕre only left with stuff MIF is still doing, and ULA.
Brian: Targeted at enterprises, so itÕs different and useful. Summary:  wait

Introducing IPv6 vulnerability test program in Japan
Ruri Hiromi
Vyncke: all in Japanese?  Yes.  DOS to router or host?
Outcome: not a WG document

Discovery of the IPv6 Prefix in 464XLAT
No presentation

IPv6 Extension Headers in the Real World
Fernando Gont
Packets with 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
Thus, if you design stuff relying on EH that uses the Internet, you need a
fallback mechanism Several comments about how terrible it is that people are
dropping packets with EH. In a network that filters EH, thereÕs a
vulnerability: an attacker could send Packet Too Big, resulting in atomic
fragments, which require EHs, so traffic gets dropped. Dave Thaler: dropping
IPv6 EHs Òfor security reasonsÓ (to avoid DOS attacks) simply creates an
alternate vulnerability (for DOS attacks) Tony Hain offers to host measurement
tools, too Draft authors Jen Linkova used Atlas probes, Fernando used his own
tools Eric Vyncke: can we identify the problem ASNs?
        Would also test on his p2p network
Mike Ackerman: what can we do about it?
Nalini Elkins: Is it that 90% on one network and 1% on another network are
getting dropped which totals out to the percentages above? Joel Jaeggli: I have
to find the L4 header, so I make edge decisions about what to drop, but they
only affect me Merike Kaeo: need data on mobility and IPSec Would you like to
see a data development study as a WG item? YES: hum, NO: slightly weaker hum Do
we want a draft that would work through recommendation on how to configure?
YES: Very weak hum, NO: even weaker Outcome: Split the document into problem
measurements and recommendations

Design Choices for IPv6 Networks
Victor Kuarsingh presenting
Dave Thaler: Right now, content doesnÕt match scope of title and abstract. ItÕs
okay to identify Òfuture workÓ or other documents.  ULA, DHCPv6 vs SLAAC; at
least say, ÒHere are some design choices discussed in other documents.Ó
Security Considerations section is TBD, do not go to WGLC
        SeND, SAVI, etc. etc.
Jen Linkova: Say ISIS multi-topology.  Saying LLA doesnÕt go beyond link turns
out to be untrue. Eric Vyncke:  Go to WGLC quick, before scope increases. 
Tighten title and abstract and go.  DonÕt forget to mention EH. To do: Change
title and abstract Add ULA, DHCPv6 vs SLAAC references Add Security
considerations Outcome: Make those revisions, then solicit review (maybe via
WGLC)

A Special Purpose TLD to resolve IPv4 Address Literal on DNS64/NAT64
environments Hiroaki Hazeyama Dan Wing: Yes, there are still problems with IPv4
literals Andrew Sullivan: I think NAT64/DNS64 is a kludge, and weÕve always
known this was going to break. Strongly opposed to creating a special purpose
TLD. If you must, use v4only.arpa Joel Jaeggli: I know of a company that embeds
v4 literals in HTTP. Surprisingly often a problem in apps other than web
browsers.  Also may break SSL. Dave Thaler: yes, doesnÕt cover cookies. 
DoesnÕt mention that DNSSEC doesnÕt work. DoesnÕt mention 464xlat as an
alternative. Erik Nygren: cookie problem should also be in security
consideration section. If we need to do this for IPv4, consider whether we
should do it for IPv6 literals. If thatÕs bad, it may also be bad in IPv4.
Cameron Byrne: have you tested this?  I did something similar, and Apache
virtual host expects name in header to be the same as the name.
        Maybe we should say ÒIPv4 literals should go away.Ó  As in rfc1958.
Joel Jaeggli: Referring URL case where it breaks is when you expect to see the
IPv4 literal. Outcome: update, and take to DNSOP

Considerations on IPv6-only DNS Development
Lianjing Song
Mark Andrews: Android isnÕt an IPv6-compliant node because it doesnÕt support
EDNS0.  512bytes isnÕt an effective limit anyway. Erik Kline: How do you know
EDNS0 works everywhere? Mark Andrews: Yes, I have been measuring EDNS0. IÕve
found exactly one server (.is) that blocks on 512bytes. Cameron Byrne: Not so
much the auth servers, but itÕs the endpoint support for EDNS0. We just heard
from an Android developer asking if it works.  Dear DNSOP: please develop EDNS0
Happy Eyeballs. Mark Andrews: CanÕt we just get IPv6 hosts to do the right
thing? Andrew Sullivan: I know there are endpoints (and proxies) that canÕt do
EDNS0. Frankly, message sizes are getting bigger and people are counting on
that. We canÕt come up with another kludge. If Android is broken, itÕs broken.
If middleboxes are broken, theyÕre also broken. Erik Kline: I would love to see
EDNS0 support in Android.  How many home CPEs will do bad things with this
kludge, and the implied performance problem. Outcome: Take to DNSOP and SUNSET4.

IPv6 Considerations for NFV
Hui Deng
ÒFloating IPÓ means NAT
John Brzozowski: OpenStack networking isnÕt networking, itÕs bridging large
domains. Fred: See other drafts with ÒopenstackÓ in the title Outcome: Discuss
on mailing list