Sunset4 WG meeting, IETF 87 Wednesday, 31 July, Afternoon session II, 1510-1610 CEST Note taker: Ole Troan Jabber Scribe: Agenda Bashing ============== -> no comments Simon Perreault, Sunset 4 Gap Analysis ====================================== http://tools.ietf.org/id/draft-ietf-sunset4-gapanalysis ** No questions Andrew Yourtchenko to discuss ipv6-disable-ipv4-proxyarp?) ========================================================== Ted Lemon, no hat: Extremely important work. Wants to see what happens when a host sends a packet ... you don't want to wait for ARP to timeout. OpenVPN doesn't notice that it has an IPv6 address, because it has an IPv4 address that looks like it might work, but doesn't. Stuart Chesire: A bit misnamed draft. It is not proxy ARP. It is just ARP. The intention of the link-local RFC is to transcend network misconfiguration. If it might work you might as well try it. I'd support a more intelligent getaddrinfo(). Andrew: In the case of IPv6 only applications. Sorting in getaddrinfo() doesn't help. SC: Too extreme solution Dave Thaler: This is only a problem if you cannot use a DHCPv6 option that there is no IPv4. Defending the rule; there might be an intermediate state where the host has an IPv4 link-local only, and can talk to other hosts on the link. AY,DT discussion ensues. Defending that the ARP for everything rule should not be changed. SC: Dave is right, one usage scenario is that you have a single physical link, temporary failures or permanent state, e.g. printer only has a IPv4 link-local address. Printer stops working if you outlaw. TL: IPv4 link-locals are broken. We didn't allow an IPv4 host to have two addresses. A link-local and a global. AY: Lots of unecessary ARP traffic on an IPv6 only network. DT: IPv4 link-local addresses are not particular to any application protocol TL: We're making a judgement call here. Matter of opinion. We want the problem that hurts the most people to get fixed. DT: You should have the DHCPv6 option. SC: Agree with Ted, this is an important issue. We should look into it. I don't think we should leap to this solution. Maybe an alternative way is to not return address records to these hosts that don't have IPv4 connectivity. Worry about the side effects. AY: I'm very open to solving it in a different way. Chairs: It makes sense to separate the problem from the solution. The solution is a lot less agreed upon. Incorporate the problem statement in the gap analysis draft. Use AY draft to track the solutions. Gang Chen, Analysis of NAT64 Port Allocation Method =================================================== http://tools.ietf.org/html/draft-chen-sunset4-cgn-port-allocation-02 Chairs:(Wes) As no hat feedback. Because there are multiple drafts, it would make sense to work together to combine the documents, to cover the space completely. When a more complete solution comes forward we can consider adopting this as a working group item. Hiroaki Hazeyama, DNS A record filter ===================================== http://www.ietf.org/id/draft-hazeyama-sunset4-dns-a-filter-00.txt Marc Blanchet: Diagram slide. There is a well known attack a device that intercepts DNS. The fact that you are dual stack, how is this different from an attack? HH: Good question. We'll consider in next revision. Ted Lemon: It sounds like this is an experimental stage. It sounds like solving the same problem as Andrew Yortchenko's draft. In the long term it seems to make sense to do this in the DNS64. Simon P: Instead of filtering DNS, instead you provision a host route to the DNS resolver. And it will fallback to IPv6? (scribe note: missed some logic). HH: Explains that IPv4 is only in the local subnet. Wes George: Problems slide. There are some good things in the observed problems.I'd like to suggest that the authors of the gap analysis draft to look at this to see if it is covered. Dave Thaler: Filtering A records. You didn't say if that applied to the additional record section. The additional record section in DNS64 says to pass it unchanged. If it is DNSSEC protected, does DNSSEC still work? [10:02] Dave Thaler: the DNS64 RFC (RFC 6147) section 5.3.2 says "The DNS64 MUST pass the additional section unchanged." Filtering A records out would require a doc that Updates 6147. [10:04] Dave Thaler: Ted also reminded the room that DNSSEC when used with a "security aware non-validating resolver" means the DNS server (here a DNS64) validates and tells the client it's validated (and may send it something else, as DNS64 does when it does synthesis on a AAAA rquery), which relies on a secure channel between the DNS client and DNS server. So filtering A out is ok in this case. If the client is a validating resolver, DNS64 doesn't work either so filtering A records doesn't change that. TL: Two scenarios for DNSSEC validation. DNSSEC aware resolver talking to a real DNS server without any DNS64. If you do DNS64 you have broken validation. You have to rely on the DNS64 server. Therefore the DNS64 bit can set the AD bit. Andrew Yortchenko: Question on the tests you did. Another possible workaround would be to not filter A records, but instead give the default gateway and block requests. HH: That doesn't work for some legacy OSes. MB: In your slide you say private IPv4? HH: RFC1918. MB: If you have a global IPv6 and a private IPv4. And you are not in an IPv6 only subnet. I'm not sure if we agree on IPv6 only subnet. Andrew Hutton, Interoperability Impacts of IPv6 Interworking with Existing IPv4 SIP Implementations ==================================================================================== http://tools.ietf.org/html/draft-klatsky-dispatch-ipv6-impact-ipv4-01 Chairs: Might drive some gaps, one of the areas we haven't uncovered all the gaps. Chairs, Joint Meeting intro – Why are we here? ============================================== Wes, representing the chairs present background and sets the framework. No comments. Simon Perreault, Turning off IPv4 Using DHCPv6 ============================================== http://tools.ietf.org/id/draft-perreault-sunset4-noipv4 Eric Vyncke: Two routers on the same segment, conflicting ideas. Two DHCP servers. Ole Troan: Configuration error. Wes George: Eric's comment made me think. Most of the things homenet is working on is predicated on the notion that we have multiple routers in the network. We have to handle this in a multirouter network. Ole Troan: You might have a network with IPv4 locally and no IPv4 external connectivity. Lorenzo Colitti: Include both (RA, DHCPv6) Dave Thaler: The other working group is MIF. People objecting to one domain affecting the other. Lack of consensus. I don't know if that should affect adoption. TL: The way you got this described, knowing the use models. You can't get away with this without DHCP PD, you can't get away without RA. Initially I was a little skeptical of it, but listening it might not be so bad. Andrew Yourchenko: Is there a level, disable IPv4 on this interface? DT: 0,1,2 is what happens on this interface. Level 3 includes also disable the loopback interface. Removing level 3 removes the conflict between sunset4 and MIF. SP: Level 2 also includes all interfaces, level 3 propagate downstream. Chairs: Sense of the second question. Are there issues that would prevent adoption? Lorenzo: Isn't the first question not contentious. DHC is looking at it anyway. Chairs: If you think there are still issues that present humm: ** a hum or two only. Presenter Q. Sun, DHCPv4 over DHCPv6 Transport ============================================== http://tools.ietf.org/id/draft-ietf-dhc-dhcpv4-over-dhcpv6 Wes George: Does it make sense for us to use this infrastructure for anything we use to communicate IPv4 preference? In my mind it seems like a natural fit to also provision a preference for the IPv4 we are now provisioning. Marc Blanchet: The IPv4 stack has to run some DHCPv4 client in some way. WG: Most of these things are reliant on updated DHCP stacks. If we update them we should update them once. Bernie Volz: The device had already to do DHCPv6. Ted Lemon: Architectural idea. What's the purpose of DHCPv4 over DHCPv6. The flag doesn't fall under that purpose. Tomek: DHCPv4 over DHCPv6 is an IPv6 packet. It is still better than IPv4. TL: Are we only talking about this draft only in the context of sunset4? Chairs: Yes. B.Rajtar, Provisioning IPv4 Configuration Over IPv6 Only Networks ================================================================= http://tools.ietf.org/id/draft-ietf-dhc-v4configuration Francis Dupont: Comment on the requriements / solution table, slide 5. If DHCPv4o6... *** Andrew Yortchenko: If I take Openwrt codebase and I try to implement any of these approaches? BR: Not an implementation document TL: If I was going to do it, I would take existing code and wrap it in a DHCPv6 packet. FD: There is a common misconception about DHCPv4. It is not over IP. Wes George: Requirements. As someone who is looking at defining new DHCPV4 and/or DHCPV6 options. How are our new options going to work with regards to requirement 5 and 2? TL: Item 5 is not saying that you cannot put something about IPv4 into DHCPv6. It is unrelated to what you would be doing in sunset4. BR: You just create a new DHCPv4 option. Bernie Volz: Take out existing in option 2. Wes: You can add new DHCPv4 option -> Yes. Dan York: Clarifying? What's the relationship with this and the one we just saw? BR: Lists all possibilities. **PRESENTER**?, DHCPv6 Dynamic DNS Reconfiguration ================================================= http://tools.ietf.org/id/draft-wing-dhc-dns-reconfigure Simon P: This is quite interesting. Useful bit is having the relay that there has been a state transition. The server can then do whatever it likes. Presenter: The relay will now just give transition. It is up to the server to comprehend the information Marc Blanchet: Change of state would likely be because a link started to receive RAs. All clients will receive RA at the same time. Relay will initiate state change for all clients. Presenter: If a host only got a IPv6 only, then the relay doesn't do anything, if an IPV4 only became dual stack. But agree there is a flooding issue. Haven't really figured out how to deal with that. TL: Since UDP isn't reliable. What if you have two relays in a fault tolerant mode. Since they are keeping state... Lorenzo: Are we asking how before should? Is there a use case? Can this be useful in sunset4. When you are ready to flip the switch aren't you willing to wait for lease timeout or reboot? PresenteR: The use case was if you were a network operator doing NAT64, sends regular DNS server for dual stack clients, and DNS64 to IPV6 only hosts. Wes: ... Mikael Abrahamsson: This is useful to give different DNS servers to different types of hosts. I've already had this problem. My idea was to have DNS queries to say if it wanted DNSv4 or not. Harald Albrecht: The relay is now keeping state of the clients on the link. What happens if it loose state? Restarted whatever? I remember attacks on routers, by making them resolve neighbors all the time. How do we protect against these attacks. Presenter: In case it loose state, it will send state again. HA: So it can easily cause amplification attacks. Lorenzo: What does dual stack mean? Link-local only, private address?? Presenter: Supports both IPv4 and IPV6. **Discussion ensues** FD: *not getting point* Andrew Yortchenko: It is easy to detect when a host gets IPv6. If the first-hop device does something... **Discussion continuing** Discussion Chairs: Any generic comments on sunset4 and dhc coordination? Lorenzo: General comment that hitching this horse to DHCPv6 or only focusing on DHC, only work on clients that do DHC today. Don't focus too much on DHCP. Ted Lemon: The reason we propose we do this session is because there is a crossover, not because we want to push DHC and sunset4 together. There are overlaps with other working groups. The overlap is very clear here. Creating awareness to make people think of the cross over. Sunset4 doesn't have to pass everything it does over to DHC... Chairs: DHC experts, do you have any problems with the current direction we're going? TL: When the option was first proposed I was dead-set against it. I still think that we need to think very carefully about the security implications of the option. Do we really need these options? Can be just figure it out from the network.. well, no it is quite useful to have. It isn't a bad approach. I don't have a better solution. Bernie Volz, DHC chair: The option follows the guidelines. We'll work with you as needed that it stays sane. Chairs: Thanks for participating.