IPv6 Operations - IETF 95 14:00-15:30 April 4 Chairs: Fred Baker, Lee Howard Minute taker: Ole Trøan Jabber scribe: Mikael Abrahamsson, Alejandro Acosta Chairs: Introduction of agenda. No comments on the agenda. Operational Implications of IPv6 Packets with Extension Headers Pause while waiting for the slides. Fernando Gont presenting. Eric Vyncke: Positive document. My question: How did you get the content of this document? FG: We talked to several operators. I can't claim this is the opinion of the operators. EV: Did you this document on NANOG or RIPE mailing lists? FG: Not sure, I usually do that. Fred Baker: A HBH header can force a packet to a different path (slow path). That issue is being looked at in 6MAN. If I find a HBH option in the packet and the only option is the pad, and hardware forces the packet off the path, is a DOS attack. How does enforcing a maximum length of the packet help here? FG: If the packet is short enough it can be processed in the fastest path. You have to resort to software processing. *Discussion on enforcing cap on extension header chain* Mark Townsley: Interesting that in an operational group you have a long discussion about how to design ASICs in the forwarding plane. Why would we try to encode limitations on hardware that exists right now? FG: We try to make it clear that if you operate outside those boundsthen thingss don't work. Joel Jeaggli: It isn't as much that we design ASICs. I did realise this morning that my understanding was from routers built in 1998. Perhaps we can parse the header longer, we're also making some assumptions what we have today and what we have in the near future. The future looks like a lot like the near present. Mark Smith, remote: Our imagination is limited and is currently constrained by what we have done and shouldn't indicate what we can do in the future." Question is, are E.H.s the right tool for these problems people are solving. Mark Townsley: Our imagination is limited. Let's not put any hard scalbility bounds in protocols. A hard scalability bound is like a 32 bit address or a 640kB limit. RFC5281. Joel J: We shouldn't take the blame for the protocol designers, and if there are problems we should talk about them, cause we are operators. Bob Hinden: The way I think about is, is to create limits about how things work today is going to hurt us later. We should not provide guidance of how things work now, that might change 5 years in the future. Fred B: What advice can you give Fernando G on what would be useful in this document? Tim Chown: Think this is useful. The first two points in the action plan about more granularity in filters and advice on filtering is useful, you should be more careful about the cap of length of extension headers. "The longer you make the extension headers the higher drop probability they have." FG, TC discussion on a concern about putting a number on it. Lee: Close the mike soon. EV: The last one is a snapshot in time, I consider this not a good way to go forward. Mikael Abrahamsson: Filtering instead of being dropped. Mike Ackerman: This is necessary, to make things work well. Encourage hardware vendors to be able to parse further. Mark Townsley: Imagine 15-20 years ago, there seems to be lots of router that only supports one MPLS label, then you would never had VPNs or loop avoidance, all the cool things you can do with multiple labels. This is a self correcting problem. If operators want to give advice to vendors, then give advice to be more flexible. Fred Baker: What guidance does the WG give to Fernando? I saw three consensus operating. I don't think we can take this as a WG document now. What does the WG like to see in this document, so there is good guidance to 6man / vendors? Tim Chown: We seem to have some sort of consensus in the room, what are the reasons for not adopting it? FB: Part of the issue is Bob's comment about this being a self correcting problem. Tim Chown: If we took out the 3rd point would it be more acceptable? FB: There is a draft in opsec. Fernando Gont: The discussion is that you shouldn't go and look deeply into the packet. Mark T: I'm frustrated by all three of these. If we don't think we understand what we can do in the future, you want to filter something for security reasons or for policy reasons. Ole T: It is paradoxical that one working group is writing protocol specifications and another IETF working group is writing recommendations to break those protocols. Christian H: A license to drop packets. Tim Chown: Simple security is a counter example. Lee Howard: Operator hat. We can provide guidance. I have a network, sometimes I can drop packets, because routers fall over for certain packets. Lee Howard / Ole Troan: We are allowed to say something, I can't ever say that we will never drop a packet. OT: But we shouldn't make recommendations based on vendors bugs, or operator policy. Fernando G: When we see a high drop rate from measurements, the impression was this was because of operator faults. They don't know what they are doing, but they do know what they are doing. The only option they have is that they drop these packets. There is a reason for them to do this. Lee: Chair hat on, looking for working group consensus. Is there more that need to happen to the document before that can happen? Mark T: Why did we separate the reasons from the results? FG: This is from talking to operators. This explains the intention behind the drops. Fred B: I need to bring this to a close. We need to take this to the list. We don't see consensus on the list. The guidance that you have been given today, is please don't think of limits, but rather what you want supported. We have to take it to the list at this point. Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership * Lots of audio problems * Mark Smith presenting Eric Vyncke: Rotuers and switches don't listen to MLD. Mark Smith: Dave Thaler: I understood the intent. Very good presentation and good thing to think about. Ole Troan: SAVI and efficient ND / address registration are alternatives. IPv6 deployment in LAC: successful and not so successful stories LACNIC report on IPv6 deployment in Latin America Presenter: Guillermo Cicileo Fred Baker: Difference between IPV6 ready and IPv6 CPE customer? CG: If the ISP is able to deliver IPv6 to the customer versus customer having IPv6 ready CPE. Barbara Stark: You said the CPE was not IPv6 ready. By that do you mean that they use UNH IOL IPv6 ready and comply with RFC6204 and still not work? CG: When they say it is not ready, when they did testing, not all the features work. E.g. prefix delegation or combination of configuration don't work. They don't have to update the firmware or make some changes to equipment. Tim Winters: Two things. We are seeing a change, we have seen problems in the past .