IPv6 Operations - IETF 99 13:30 Thursday 20 July 2017 -- Reporting of Happy Eyeballs v2 Failures 2017-07-03, Jordi Palet Martinez Fred Baker: We don’t define protocols here. This belongs wherever syslog work belongs. Waren Kumari: Asking for a well-known anycast address is not really defining a protocol. Eric Vyncke: What is the incentive for anyone to implement and/or deploy this? Ondrej Caletka: This won’t work without NAT64 Jordi Palet Martinez: This does not need NAT64 or DNS64 Ondrej Caletka: This will interact badly with lingering uses of 6to4 Jordi Palet Martinez: But 6to4 is deprecated Waren Kumari: That doesn’t mean no one is still using it Waren Kumari: There’s a big DOS vulnerability here Jen Linkova: I see very limited use for this. Perhaps within an enterprize network. David Schinazi: Syslog messages of IPv6 failures may have serious privacy implications Private web browsing may not be private if your client device is logging failures into an unknown syslog server We should not try to integrate this into RFC6555bis; RFC6555bis document is almost done; this still has a long way to go Mikael Abrahamsson: The idea here sounds useful, but there are a lot of details to work out -- Considerations For Using Unique Local Addresses 2017-03-13 , Bing Liu Merike Kaeo: Why are we even discussing ULAs? Fred Baker: A ULA is a firewall rule implemented in BGP I don’t understand the opposition to ULA Lorenzo Colitti: ULA can create a false sense of security If you’re on an adjacent network, just because I don’t advertise a route doesn’t mean you can’t send a packet to me Erik Kline: Good that the document states that ULA addresses are not RFC 1918 addresses Document needs to say ULA + NPTv6 is “not recommended” or “NOT RECOMMENDED” Tim Chown: Many people do seem to use ULA without trouble. Ronald Bonica: This document can be shortened to just a couple of pages. Victor Kuarsingh: I agree: Document needs to say ULA + NPTv6 is “not recommended” or “NOT RECOMMENDED” Lorenzo Colitti: Lots of existing walled gardens work fine using GUA global addresses Tim Chown: UK universities are creating ULAs manually, instead of including the random part Victor Kuarsingh: I agree with Lorenzo. Marcus Keane: We find it’s better to use GUA global addresses instead of ULAs -- Using Conditional Router Advertisements for Enterprise Multihoming 2017-06-14 , Jen Linkova Fred Baker: I’m trying to work out how to implement this Timothy Winters: Why not use route information options? Jen Linkova: Not all platforms support RIO David Lamparter: I support this and plan to implement it Do the policy rules need to include more than just checking the routing table? Tim Chown: Could some external device monitor the network and send commands to the routers? Jen Linkova: It’s better if the routers do this detection for themselves Lorenzo Colitti: It is useful for us to document the current behaviors of today’s hosts which may have software from ten years ago. This is what operators need to know. Waren Kumari: Most implementations do VRRP tracking already, so this could be done in a similar way. Thaler: What if both uplinks are down? Leave both deprecated. Both addresses still exist; they’re just not preferred. Mikael Abrahamsson: There is prior art here. RFC 7084 talks about what to so when WAN link goes down. The Homenet code already does something like this. Timothy Winters: We should add RIO too, for future hosts that support RIO. Mikael Abrahamsson: I would like to see more work on the control plane Jen Linkova: This mechanism is independent of the control plane that controls it Darren Dukes: How fast is the propagation? Jen Linkova: That’s hard to say right now because of vendor bugs. Pierre Pfister: I support this. This work is compatible with RFC 7084 and Homenet work. Lorenzo Colitti: Helping to get vendor bugs fixed is a good reason to publish this. David Schinazi: I like this work and support it. Fred Baker: Call for hum on adoption Reject outright? Silence Consider later? Weak hum Adopt now? Strong hum -- Requirements for a Zero-Configuration IPv6 CPE 2017-06-17, Fred Baker Bob Hinden: The router I have is less of a horror story Timothy Winters: We should make having IPv6 enabled by default a requirement for using the “IPv6ready” logo Barbara Stark: The only significant IPv6 success stories are when the ISP provides its own home gateway, already configured correctly Jordi Palet Martinez: Look at RFC 8026 Lorenzo Colitti: The document is overly detailed. We want implementers reading and complying with RFC 7084. Hans Liu: D-Link is working to improve this issue Victor Kuarsingh: I have never seen a router that comes with IPv6 enabled John Jason Brzozowski: We should include a specification of what a router should do if it gets no IPv4 address. Joseph Abley: D-Link currently has a line of 31 different home gateway models, all with IPv6 enabled by default Barbara Stark: AT&T-supplied home gateways do IA PD. Mark Townsley: D-Link was involved with World IPv6 Launch in 2012. Initiatives like that are needed, not only more RFCs. Fred Baker: What are next steps? Sorten the document? No specific actionable conclusion was reached. -- RFC 7984-bis in four parts Basic Requirements for IPv6 Customer Edge Routers 2017-06-12 , Transition Requirements for IPv6 Customer Edge Routers 2017-06-12 , Minimum Requirements for IPv6-only Customer Edge Routers 2017-06-11 , Basic Requirements for IPv6 Customer Edge Routers with HNCP 2017-06-11 , Jordi Palet Martinez Barbara Stark: We should be wary about updating RFC 7084 unless we really need to Timothy Winters: S-2 (ingress filtering) was a “MUST” in RFC 6204, but got downgraded to “SHOULD” in RFC 7084. We should revert that to “MUST” Mikael Abrahamsson: I agree with Barbara Stark. We should not update RFC 7084. We should have a new RFC for transition mechanisms.