V6OPS Active WG drafts o HTTP://tools.ietf.org/html/draft-ietf-v6ops-scanning-implications "IPv6 Implications for Network Scanning", Tim Chown, 26-Oct-06, Tim walked through the changes to the -02 document. Dave Thaler: Dave Thaler: This question was raised by Pekka on the mipshop list and is relevant there as well. Fred: You want to rerun the WGLC? Tim: I think that would be the best thing given the scope of the changes. Fred: I want 3 reviewers Dave Thaler, Joe Abley, Jonne Soininen volunteered. o Myung-Ki Shin HTTP://tools.ietf.org/html/draft-ietf-v6ops-802-16-deployment-scenarios "IPv6 Deployment Scenarios in 802.16 Networks", Myung-Ki Shin, 16-Feb-07, Changes since last meeting is based on extensive review from the 16ng WG. -02 was published after this. WGLC completed Feb 11. Just two comments received during WGLC on reference section. -03 draft published. Next steps? More review or send to IESG? AD says IESG want to see that v6ops care about this work. Fred: What is the feeling of the room? Are we ready to publish? How many read it? Of those of you who have read it, do we want to publish it? Kurtis: Can I suggest that we do a short 1 week WGLC and require at least 5 people that can prove they read the document to comment and support it? Fred: Let's do that. Jim Bound: Is "I agree" enough? Fred: Yes, I am looking for support Kurtis: Jim, I was looking for people that have read it as a start... o HTTP://tools.ietf.org/html/draft-ietf-v6ops-addcon "IPv6 Unicast Address Assignment Considerations", Gunter Van de Velde, 26-Oct-06, Gunter walked though changes to the -03 version. WGLC completed Dec06. Not many comments but quite detailed. -03 was issued in March. Most changes where editorial. Some changes where more substantial. We also added some text on multihoming and sizing of network allocations. Text on using /126s was added. Alain Durand: /126, isn't that a violation of another specs? Gunter: Is it? /127 is? Alain: ADDRARCH says it should be /64. Dave Thaler: For anything that isn't 000 - yes. Outstanding questions: - Relocation case-studies to an appendix - ULA blocks larger than /48? Dino: Embedded RP and Unicast address on your last slide. If you have a more specific address and you are given a less specific address, where do you send the join? Is that corner case documented somewhere? Dave Thaler: From my understanding both v4 and v6 embedded RP is based on routing on a specific unicast address and not a prefix, so it's longest prefix match. Fred: Let's rerun the WGLC. I really want to see comments that this addresses a specific problem. o HTTP://tools.ietf.org/html/draft-ietf-v6ops-campus-transition "IPv6 Campus Transition Scenario Description and Analysis", Tim Chown, 16-Oct-06, Tim: There was some minor editorial changes. Two public comments and three private. Fred: Do we see this as important and useful? Brian Carpenter: I think this is very interesting and useful to the community, but is it RFC material? Or an O'Reilly book? But I don't want to see the material lost. Fred: Based on the comment that it shouldn't be lost, let's move this to the IESG. But we won't do another WGLC. o Marc Blanchet HTTP://tools.ietf.org/html/draft-ietf-v6ops-routing-guidelines "IPv6 Routing Policies Guidelines", Marc Blanchet, 27-Feb-07, This came out of a discussion on how to do filters at peerings and FW filtering rules. Changes to the -00 WG version, all comments that where received are included. next steps: I-D nits fixes needed. Unless more comments issue -02 and then WGLC. Alain Durand: What is wrong with 2772? The document is not wrong, but it references the 6bone. Pekka Savola: I think I stated this before, now if we exclude routing policy from the document, which I support, then what we have is a list of special prefixes for IPv6, like RFCXXX that we have for IPv4. Perhaps we should fold it in there or rename it into special addresses instead of calling it routing guidelines. Marc: I am fine with renaming but it is a bit more than just a list of addresses, for example the considerations of Teredo and 6to4. Also, the first thing people starting with IPv6 is, what should I filter? Bernhard Tuy: I would not say it's not useful, but I am not sure we need this in the IETF framework? This is not the right place to give ISPs filtering guidelines. Fred: If you ask me, yes as we gave them those reasons to filter. Marc: Removing the maximum prefix-length there is no real data on the IETF telling the ISP how to run the network. The remains also apply to FWs. Bernhard: We are trying to say here are the filters you need to apply on your routers. I am not sure? The registries should perhaps do this? Alain: It comes with recommendation in the title. I don't think the IETF can tell the operators what to filter. Joe Abley: We find 3430 very useful and would like a similar v5. Danny McPherson: I agree with Pekka that we should decouple the filtering of bogons as we are seeing all these problems with bogon filters not being updated, but the other filtering rules are need. Marla Atzinger: I would like to commend you, I think you are doing a good job and would like to see this move forward. The word mandated is not in the document. to continue on the list. Reviewers: Alain, Joe, Iljitsch. o Ruri Hiromi HTTP://tools.ietf.org/html/draft-ietf-v6ops-addr-select-ps "Problem Statement of Default Address Selection in Multi-prefix Environment: Operational Issues of RFC3484 Default Rules", Arifumi Matsumoto, 10-Nov-06, No additional comments on the problem statements. Please review it and send comments to the list. o http://tools.ietf.org/html/draft-ietf-v6ops-addr-select-req "Requirements for the address selection mechanisms", Arifumi Matsumoto, 21-Feb-07, Ruri walked through the new document. Next steps: additional comments for those two drafts are encouraged to be sent to the list so that we can get ready for WGLC. Alain Durand: Why is multiple I/F cases a should and not a must? Ruri: At the last IETF, we got a comment that we should include this. We don't really have a strong opinion one way or the other. If people think it should be must, we will canoe it. Alain: I think it should be a must. Fred Baker: My working guidelines for the word "MUST" is that something breaks if you don't use it. Alain: In a production environment all servers if have multiple interfaces so it this is not supported its use in a production environment becomes less. If the we are ready with requirements and PS we want to move to solutions. o Solutions to addr-sec, Arifumi Matsumoto Four possible solutions presented. Proactive approach 1/2 Dave Thaler: I am not sure if that is true as one of the requirements for 3484 was to support multiple interfaces ans DCHPv6 works per interface. Dave: It certainly requires some change to support DHCPv6 options. You might get away with minor changes to 3484. Proactive Approach 2/2 Alain Durand: I think this is a good thing as smart applications will benefit from more information. Where the things that will benefit the more will pay the price for it. Reactive approach 1/2 Joe Abley: Is the mechanism for ICMP redirects in IPv4 similar? Jim Bound: I think this is fine, the way you approach it. All of this has to be a should, the reason for that is that the majority of the nodes of the network is fixed. This is quite heavy additions. This can never be a must as ND etc. It's a nice suggestion, and I have issues with RFC3484 in general. ??: As this looks like ICMP redirects, which was disabled for security reasons that should be noted. Iljitsch van Beijnum: I want to disagree with Jim. If I have to go from user mode to kernel mode there is a high price to pay for that, but if you are communicating across the Internet you will have to look into DNS etc. Kernel space is in micro seconds, and DNS is lookups in the millisecond space. Alain: I would agree with Jim. Jim: I agree with Iljitsch, but I was addressing Alain, that we can't assume certain behavior in the specs. In user space we eat the cost of general lookups. In kernel space it's different. It might work on the clients, but not on the Any other solutions? Please send to the list? We will proceed to Joe Abley: It seems that the whole address selection problem is tightly bound to the site exit router selection. I see very little discussion around the later, and I think they are very tightly connected. If IPv6 ever get deployed as widely as IPv4 we will run into problems with BCD38 and site exit selection. Arifumi: Yes, we also need to look at next-hop-solution, but there are other solutions for that. Alain: I remember in the old days of multi6 that there was a draft by Christian Huitema that used ICMP for this. Dave Thaler: It was picked up by Marcelo and is now an individual submission. Joe: I think that work should be picked up by this working group. Markus Stenberg: I just wanted to point out that some of the host based solutions can address both problems but with a network based solution they can't address this. I think it's good to keep both problems in mind and not focusing on one or the other. ???: when you are thinking of large scale solutions you should think of the effects of a large population talking to the routers with this and is it cheap for the routers to do this. Think scenarios such as campuses etc. Arifumi: In the problem statement we considered this. For the solutions we should think about in what environment they are being deployed. Fred Baker: I didn't understand the two last comments, it doesn't scale to large network so let's focus on small networks? Arifumi: No, we need to look at the solutions and where they apply. Tony Hain: I think that was he was saying is that he might end up with several solutions, that have different scaling properties. Arifumi: I agree with you. Fred: I want something that can be implemented by MS and Apple and be used by my wife. Tony: That is not the same as a solution that is used by an enterprise or a campus. o Firewall and IDS, Tim Chown Tim talks about firewalling and IDS in a dual-stack environment. As there is a lack of support for an integrated solution for both cases, Tim walked through their current installations, solutions and observations. Jim Bound: there have been SNORT ports to IPv6 but they won't release the code. There are also vendors that can do deep packet inspection, even for IPv6. Tim: Could you send this to the list? Jim: Is that ok? Fred: Yes Iljitsch: You are talking about strange manipulations of extra headers in the IDS. Have you seen any problems with the firewall with the extra headers? When I tested this some years ago I saw some strange behaviors. Tim: Good question, but we haven't looked at dumps on the packets that get dropped by the firewall. Alain Durand: I have a question on the FW activity you are seeing. Is there a relation between the v4/v6 fw activity and your IPv4 and IPv6 traffic? Tim: No, because most of the IPv6 traffic is streaming traffic. Ralph Droms: Quick administrative question, will these slides be posted? Fred: They are. Jim Bound: As I think you know there is a firewall paper on the IPv6NATF. I think this is good work, what do you think about an end-to-end security model? If you have everything encrypted including the header, a lot the security becomes harder. Tim: I think that if we are looking at turning this into an I-D we need to look at this. Jim: I can't commit to be an author and contributor, but I can get others to commit and help. ??: With respect to firewall spec, there is a design-team in mobileIPv6 that are looking at route optimization problems that might occur from firewalling.