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