IPv6 Operations - IETF 90
Monday, Jul 21, 0900 - 1130 
Note Well
Jabber - Dan York
Minutes - KK Chittimaneni


Agenda Bashing and Administrivia
[Fred Baker]
* Most drafts came in around the 3rd or 4th of July which means most 
people didnÕt get a chance to comment
* Give the working group some time, post drafts a couple of weeks early so 
folks have an opportunity to comment on the list


DHCPv6/SLAAC Address Configuration Interaction Problem Statement
2014-06-18, <draft-ietf-v6ops-dhcpv6-slaac-problem>
[Ron Bonica]
* Draft has been reworked, new version to be posted
* Guidance for DHCPv6/SLAAC updated - clearly stated two motivations for 
coexistence
* Open Question to WG - There was concern that SLAAC/DHCPv6 from the 
same prefix might cause some applications to fail - there havenÕt been any 
reports of this happening, please report if youÕve seen it
* Next steps - Problem Statement - Do one more rev for grammar and 
presentation
* Authors would like folks to read the guidance draft and comment and 
then call for WG adoption
[Joel Jaeggli] 
* In cases where you have Native DHCP, operating independent of SLAAC, if 
you expect to use multiple prefixes, how does that interact with potential 
renumbering activities or multihoming. If you end up with significant 
population of hosts that do DHCPv6 only that might potentially be dire with 
respect to future expectations for things working. If you need that piece of 
signaling to make this work for multiple prefixes then you might be in 
trouble. 
[Ron]
* This is not called out in the document, weÕll call it out in the problem 
statement
[Lorenzo Colitti]
* On the guidance draft - DHCPv6 only might not work at all. You donÕt 
even know how to talk on-link. You have no routing capabilities, all you 
have is link local. We should try not to imply that it will work
[Tim Winters]
* We have seen the issue that when DHCP servers are configured to EUI 64 
addresses, it causes massive issues
[Barbara Stark]
* The problem with guidance - the use case IÕve seen recently for DHCPv6 is 
in a close environment. You can only use it if you know it will work. 
[Erik Kline]
* How much testing has been done? This is good to experiment and get real 
world data
[Lorenzo]
* In guidance we have to make sure we say that this works when only you 
know that it works a priori in your environment
[Fred]
* Carlos and Andrew to review problem statement during last call
* Guidance Draft - do a readbility update on it and weÕll discuss further


IPv6 Roaming Behavior Analysis
2014-07-04, <draft-ietf-v6ops-ipv6-roaming-analysis>
[Gang Chen]
* The document identifies the failure cases with IPv6 support in roaming 
scenarios and lists known solutions
* We are expecting more reviewers for this document
* Can we get to WGLC?
* Nobody asks questions
[Fred]
* Regarding WGLC - There have been significant questions in previous 
iterations. Perhaps people donÕt have a whole lot to add
[Lorenzo]
* Silence has to do with a lack of reviews from people who are well versed 
with the subject matter. Do we have reviewers who say I know 3GPP. 
[Gang]
* The team members are all 3GPP experts
[Fred]
* Most of the author list would have been reviewers
* We will take it to LC on the list and hope that people will read and 
comment on it


JANOG Experience with ULAs
[Yasuhiro Ohara]
* Presenting this as a user, nothing to do with NTT. We donÕt discuss 
whether this is good or bad network design, just observations
[Lorenzo]
* Thank you for doing this. When we do this next time, please test v4 as 
well. In my testing, when you have v4 and ULA as well, ULAs are not used at 
all.
[Steven Barth]
* Did you see issues with ULA source address trying to reach global 
addresses. 
[Yasuhiro] - No


Considerations of Using Unique Local Addresses
2014-07-04 , <draft-ietf-v6ops-ula-usage-recommendations>
[Brian Carpenter]
* Draft has been made more neutral by replacing keywords 
ÔRecommendationÕ and ÔGuidanceÕ to ÔConsiderationsÕ
[Fred]
* With respect to isolated networks labs might exist and they might not get 
ever connected
[Brian]
* Strange things can happen during de-acquisitions and you sell a lab 
containing isolated network to someone else
[Ran Atkinson]
* Another example, I have financial clients that required that have separate 
networks. I think the draft is not as crisp in this area and there may be 
opportunity to edit the draft in this area
[Lorenzo]
* Operationally speaking, you should mention that if you have a lab, never 
say it will not be connected, the day it gets connected ,it will bite you
Can we also get rid of sensor use case, that was completely debunked, they 
still need routing.
[Wes]
* Add something about if you have v4, chances are ULA will never get used
[Ran]
* It is a bit contradictory to remove words such as 
Recommended/Guidance, but to add 2119 style language and a 
requirements language. Would prefer to see this go away and that this be 
an information draft
[Erik]
* The document references MUST and SHOULD from other docs.
[Tim] 
* My guess is so they could add the cut and paste from 7084
[Fred]
* Perhaps IDNits told them to do that
[Mikael Abrahamson]
* my problem is interaction with IPv4. Its mentioned in 4.3 as out of scope. 
My MAC is still using 3484 for address selection. We should have brought 
this out as a section of its own, more clearly stated.
[Erik]
* Some of the language relaxes the MUSTS from other RFCs, also uses 
ÔprobablyÕ in many places, would like to see that revised. Statements some 
time read backwards, IÕll send feedback to list.
[Ran]
* I donÕt object the work, but I object to the language usage. Needs some 
language assistance. Do one editorial pass before WGLC
[Lorenzo]
* We should have technical writer expertise. I think this document 
represents consensus about how we think this will work. I concur with 
Mikael, it doesnÕt work this way in the real world. If Apple doesnÕt work 
with Source address selection then we need to make that explicit.
[James Woodyatt]
* V6-only app on a dual-stack IPv4+ULA-only host will always use the ULA 
despite the availability of a higher priority IPv4 address. do we still want to 
"NOT RECOMMEND" ULA+NPTv6 in light of that observation. Personally, I 
do, but I bring it up anyway.
* Conclusion is authors need to do another pass before WGLC 


Close encounters of the ICMP type 2 kind (near misses with ICMPv6 PTB)
2014-07-03, <draft-jaeggli-v6ops-pmtud-ecmp-problem>
[Joel Jaeggli]
* This document calls attention to the problem of delivering ICMPv6 type 2 
"Packet Too Big" (PTB) messages to intended destinations in ECMP load 
balanced, anycast network architectures.  It discusses operational 
mitigations that can address this class of failure.
[Lorenzo]
* I think this is useful advice and should be called out. This problem affects 
IPv4 as well. This is not simply a bug fix there is an economic problem here 
as well
[Fred]
* What would it take 4821 into open source code? 
[Mikael]
* Response from Linux folks is that operators donÕt do it right. Operators 
might drop it by policy. Supports documenting this.
[Dan York]
* Are you seeking people to provide better workarounds for this problem? 
[Joel]
* You can hack this up in a variety of workarounds. Happy to capture all 
workarounds
[Fred]
* do a rev, post it as draft-ietf- and then weÕll go to WGLC


Free from Using Zone Identifier for IPv6 Link-Local Address
2014-07-01, <draft-kitamura-ipv6-zoneid-free>
[Hiroshi Kitamura]
This document describes "Zone-ID Free" functions that make end users free 
from using zone identifiers (Zone-ID) for IPv6 link-local addresses.
[Markus Stenberg]
* Concern is multicast is not in different, this scheme works for unicast, but 
for most you need scope id, need considerations for that
[Andrew Yourtchenko]
* 2nd para of abstract - when users need to deal with IPV6 addresses, they 
should use with service names as opposed to addresses
* In the probing section, IÕd like to have MUST not do probing
* For ping6 - using the address with zone id, there needs to be 
improvements at the kernel level
[Dave Thaler]
* Curious whether the audience is implementer or operator (6man?) What 
youÕre proposing is what Windows has always done. This is an issues with 
certain systems. If this is what OSes should do - 6man, If this is what they 
do - v6ops
[Erik Nordmark]
* you might be trying to solve a lot here. 
[Erik Kline]
* IÕd be in favor of solving this at the naming level
[Lorenzo]
* If the use case is that the user plugs in router and needs to configure it, 
we donÕt need to fix it. I donÕt see why we need to solve this problem. This 
is complex.
[James Woodyatt]
* The draft is categorized as standards, update 3542? 
[Hiroshi]
* We donÕt know yet
[James] 
* the approach in this draft is not the only way to address this problem. 
another way is to provide such logic in a software interface that provides an 
adaptation above the advanced sockets interface. in light of that, why is 
this draft necessary?
[Dan York]
* There is 6874 if this issues needs to be addressed, there is another way to 
solve this. Encourage you to look at 6874, can we adapt it to solve this case, 
concerned about multiple drafts
* It would be helpful if we can quantify how often is this an issue. Also, how 
do you see this deployed - kernel patches?
[David Lamparter]
* I did read the security considerations and I believe that is completely 
insufficient. We should not make it more insecure
[Hiroshi]
* Are you referring to an ND problem or a proposal problem, I think youÕre 
referring to ND issue
[Fred]
* This draft wouldnÕt be v6ops, but we wanted some operator commentary


Running Multiple IPv6 Prefixes
2014-07-03 , <draft-liu-v6ops-running-multiple-prefixes>
[Sheng Jiang]
[Fred]
* we had some comments on list, where do we want to go on this? 
Comments?
[Lorenzo]
* my gut feeling is that weÕre trying to put too many problems in one 
document. It would be useful to have more than one document
[Sheng]
* We donÕt try to solve the problem, many of these problems are being 
worked on already
[Mikael]
* Agree with Lorenzo, could be more precise. Good to document these. 


IPv6 Operations - IETF 90
Tuesday, Jul 22, 14:20 - 16:00
Jabber - Dan York
Minutes - KK Chittimaneni


IPv6 Flow Label Reflection Requirement
2014-07-03, <draft-wang-v6ops-flow-label-refelction>
[Sheng Jiang]
[Andrew Yourtchenko]
* There seems to be a strong assumption that connection is initiated from 
the subscriber side, did I understand that correctly. How does this work if I 
open a pin-hole?
[Sheng]
* Yes and no. Currently the end to end is a bit more applicable for domain 
management, what we can do is deploy this mechanism
[Erik Kline]
* have you considered user space implications, whether or not OSes 
support this. There is an itojun draft that you can revive, revise.
[Sheng]
* No we havenÕt considered that
[Eric Vyncke]
* In the case of stateless Nat64 or NPTv6 you donÕt get this. If I send you 
UDP with no flow-label. Does it need to use the flow label?
[Philip Mathews]
* are you trying to propose some sort of Qos related mechanism or flow?
[Sheng]
* Identify flow
[Jen]
*  Is the use case for dpi, we donÕt want to do it
[Sheng]
* thatÕs just a use case where bastion flow goes to this
[Philip Matthews]
* could this be for load balancer for NAT


Power consumption due to IPv6 multicast on WiFi devices
2014-07-04, <draft-desmouceaux-ipv6-mcast-wifi-power-usage>
[Yoann Desmouceaux]
[Unknown person at mic]
* Did you look at what happens when devices roam. What about SIP?
[Yoann]
* When you roam there is no multicast traffic produced. I havenÕt tested all 
stacks
[Fred Baker]
* seems like this could be generalized a bit, mcast messages get to an AP, 
can be held up to half a second and then send everything as a burst
[Yoann]
* you can tweak the dtim period 
[Mark Townsley]
* what can we do? modifications in IPv6 itself, something in the AP or 
something in L2, is there a message to IEEE or do both in parallel
[Ran Atkinson]
* my observation is that this problem is a problem for one radio, for most 
radio links, multicast is more efficient. optimizing things for unicast, donÕt 
generalize for single link layer
[Lorenzo]
* Some implementations do a whole attach when they wake up, we need 
to get a more complete picture, whats the damage done by mDNS packets. 
Would love to see more research numbers on total impact
[Erik Nordmark]
* letÕs understand it more, are these unsolicited NAs. 
[Barbara Stark]
* In my observation you have 4 of ND messages, 20 of everything else , 
thatÕs whats going to be going up and up, letÕs not target ND. Some home 
routers are blocking multicast, thatÕs messing this up
[James WoodYatt]
* a good message to take to IEEE is that we have good data now that says 
IPv6 multicast deserves special treatment in access points to be converted 
into 802.11-layer unicast to each group member. This is not easy for 802.11 
to address. beam-forming and disparate unicast physical rates for each 
group member make it a tough problem decide whether to multicast or to 
send multiple unicasts.


Running Multiple PLATs in 464XLAT
2014-07-04 , <draft-sun-v6ops-xlat-multi>
[Chongfeng Xie]
[Andrew]
* have you considered doing ECMP for load balancing?
A: No
[Lorenzo]
* DonÕt understand purpose of this draft, donÕt see use cases or proposal. if 
these are the use cases then whatÕs the proposal? IÕd like to see more use 
cases and detail
A: There are many use cases. Architecture is very general when deploying 
carrier network. They may have different /64 prefix. 


DAD And Packet Triplication
2014-07-04 , <draft-yourtchenko-chown-rupik-v6ops-dad-3x>
[Andrew Yourtchenko]
[Lorenzo]
* That option on the slide ÒContinue working on DAD failureÓ thatÕs a 
violation of RFCs
[Ole] 
*	We all agree that enhanced DAD will fix this
Send it to 6man.


IPv4 Address Literal in URL
2014-01-11, <draft-osamu-v6ops-ipv4-literal-in-url>
[Fred]
* Question to Xing Li - You did some research in Cernet. Is this still a 
problem?
A: Yes
[Dave Thaler]
* what entity would you expect to compose this TLD, a human, a webpage, 
a host, application or NAT64 does?
A: We want to have this when someone is browsing, typing ssh, person 
typing in
[Fred]
* youÕre plugin for Chrome what does it do? How does it work? IÕm on a 
webpage, breaks URL apart, pulls out IPv4 address literal
A: This adds suffix automatically.
[Jen Linkova]
* This will need every single application that has this problem to have this 
solution implemented. Host asking for FQDN, if I ask DNS server something, 
then I should just get what I ask for.
A: There was some explanation of how this works. There needs some re-
edits because of language
[Lorenzo]
* YouÕre expecting people to type IPv4 literals, it might not be worth it. You 
only solved part of the problem.
[Suzanne Woolf]
* IÕm a DNSOP Co-Chair - There is a process to reserve TLDs for special use. 
If you need to invoke that then make sure cross WG collaboration happens
[Joel]
* ItÕs not a question of can we do this, if these things find their way into the 
wild, it has a potential for unintended consequences. If it finds its way into 
a recursive resolver today for example.
[Andrew]
* Use case would be more when user is browsing and some web app has a 
v4 address somewhere
[Erike Kline]
* Should we take this as experimental.
[Fred]
* We would still need to take into account Suzanne WolfÕs comment.
[Lorenzo]
* we will have to do some more rigorous analysis of security and such if we 
want to take it to experimental