[v6ops] draft IETF91-v6ops minutes

[Lee Howard <[e-mail]>]

Below, my notes from this week's meetings.  I'd like some review before I
post them as meeting minutes.


Lee








IPv6 Operations ­ IETF91
Monday, 10 November 2014
 
Deprecating Connection of IPv6 Domains via IPv4 Clouds (6to4)
<https://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic>
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 preference
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
<https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations>
Bing Liu
Brian Carpenter: Is this consistent with what Homenet is saying?
Bing: Yes, currently compatible
 
 
Considerations for Running Multiple IPv6 Prefixes
<https://tools.ietf.org/html/draft-liu-v6ops-running-multiple-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
<https://tools.ietf.org/html/draft-jpcert-ipv6vullnerability-check>
Ruri Hiromi 
Vyncke: all in Japanese?  Yes. DOS to router or host?
Outcome: not a WG document
 
 
Discovery of the IPv6 Prefix in 464XLAT
<https://tools.ietf.org/html/draft-wang-v6ops-xlat-prefix-discovery>
No presentation
 
IPv6 Extension Headers in the Real World
<https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-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
<https://tools.ietf.org/html/draft-ietf-v6ops-design-choices>
Victor Kuarsingh presenting
à This needs usefulness review on NOG
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 
<https://tools.ietf.org/html/draft-osamu-v6ops-ipv4-literal-in-url>
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
<https://tools.ietf.org/html/draft-song-sunset4-ipv6only-dns>
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