o Agenda bashing Elwyn: I was going to talk about ICMP filtering as well. Fred: We will get you in. o Status of v6ops documents in the IESG, David Kessens OPSAREA are running the proto-sheparding process so it is actually the WG chairs that are doing the sheparding and not the ADs. After David's paternal leave a bunch of documents where sent to the IESG. draft-ietf-v6ops-natpr-to-experimental-03.txt We cannot move a Proposed Standard document to Experimental. Instead we need to move it to historical. draft-ietf-v6ops-icmpv6-filtering-recs-01.txt Need IETF LC, although not formally needed, it will be good due to wide interest. draft-ietf-v6ops-ent-scenarios draft-ietf-v6ops-bb-deployment-scenarios-05.txt Discusses needs to be cleared. draft-ietf-v6ops-np-02.txt Discussed needs to be cleared. draft-ietf-v6ops-security-overview-04.txt Also have discusses that needs to be cleared. David was happy with it as it is, but comments needs to be addressed. Pekka Savola: Do we need to discuss what to do with the NAT-PT moved to experimental document? Are we going for Historical or Informational? Fred: What we are saying is that we want the doc off standards-track and Historical does that. Elwyn Davies: We started down that path, but where told we had to go for Experimental. Not sure if the defenders that didn't want go for Historical are here? Tony Hain: If I recall the defense for not going to Historical is that there are products on the street that does this already and these vendors didn't want to have products sold that where based on historical. Not really a big issue. o draft-ietf-v6ops-nap, Tony Hain - Didn't have time to do the edits before the cut-off date. I will send it in ASAP. Diff file of the changes was sent to the list. - A lot of editorial changes. - Most discusses was of the type "we don't understand". Text re-arranged in order to address this. - Changed the reference to "marketing" to describe what is in the market. - There where concerns that some text appeared to be speculative. This was reworded to be factual descriptions. - Highlighted cascaded NATs as application endpoint constrained vs tane of v6 device id's. - No substantial changes, do we still want to do LC? Alain Durand: Do you still recommend using host routes? Tony: This is no BCP, it's an informational document so it doesn't really recommend anything. Text is changed to point out that there are scaling issues. Alain: I think we need a new WG LC. Margaret Wasserman: I still have concerns about host routes. Even if it isn't a BCP, it does outline what can be done but I don't understand how you would do that? Tony: I believe this was addressed in the revision? Margaret: I sent a list of five issues that never was addressed but I got mails in support. Tony: I don't think I ever saw those? Margaret: there was some issues that some people thought should be in a separate document. Tony: Why would we want those issues in a separate document? Brian Carpenter: I don't see the advantage of moving those issues to a separate document, the document is more worth as a single container. Tony: It could be an option to make a BCP on how to do things. Tim Chown: ???? ULAs the document is promoting to use ULAs, but I am not sure this is a fully matured recommendation. I think there are issues that needs more operational experience before we could try this as a BCP. Fred: You mean that when documents are read they don't pay attention to the status of the document, so it should be pointed out clearer in the document? Tony: There is an entire paragraph that points this out! Fred: Can we make sure the authors talk to Margaret to make sure her issues are addressed, then post a new version and we will do a one week WG LC? Tim: In the document NAT traversal and firewall traversal are treated as the same, but they aren't really. There is also work in other WGs trying to address those issues. Tony: could you mail suggestions to address that? Tim: Yes. draft-ietf-v6ops-security-overview, Elwyn Davies - Currently in the state where we have to deal with a number of comments from the IESG review and the sec-dir review. Elwyn believes that most of the comments are philosophical rather than substantive comments, but we need to address them. - The draft points out two holes in the current IPv6 standard. The draft currently suggests dropping traffic which is "in standard", such as fragments. Two ADs didn't like this, but the problem was acknowledged. Solution is to add a disclaimer to the draft that highlights that the recommendations in the draft will drop traffic you might not want to drop. - Unusual patterns of padding might be dangerous traffic although permitted by the spec. - A text on tiny fragments will also be added to capture what is described in draft-manral-tiny-fragments-issues-02.txt. Section 2.1.10 covers the case with firewalls that reassembles packets before filtering. Alain Durand: Overlapping fragments is also an issue. Is that covered in your draft? Elwyn: Yes we strongly points out that overlapping fragments should not be allowed. - Draft also discussed unknown extension headers, led to a lengthy discussion. Ilitsch van Beijnum: Wasn't there a big problem with deployment of ECN because firewalls dropped them and wouldn't this lead to the same issue? Elwyn: The point is that they should think of what they are filtering and actively adopt rules. Iljitsch: ??? Fred: I don't' believe that is true. The document says the Firewall admin have the option to filter. Iljitsch: This is dangerous precedent, what you are saying is that this is the base set of headers. And it will take 10 years to change. David Kessens: Do you have a solution? Iljitsch: I have no ultimate solution here and now, but there might be a way to make options to say what to allow through and not (?) Marc Blanchet: By default firewall admins block everything by default. Remember ICMP? We should try and influence vendors so that they update defaults and rules(?). Suresh Krishnan: Today everything is deny all, drop unknown. What we are saying is that known headers should not be dropped and fw admins and vendors should change defaults for this. Elwyn: What we are saying is that people should choose boxes that allow you to change these rules and keep an eye on the problem. Iljitsch: This is a precedence we are setting. Fw admins will say that dropping everything is ok. Fred: They already do! Fred does straw poll if we need to solve this issue off-line. Comes down on both sides. Fred encourages this to be discussed off-line. Finally a number of smaller issues that needs clarification, middleboxes, section 4.9 wrt privacy addresses and ingress-filtering and last using MAC addresses to identify equipment characteristics. Some items discussed that won't be addressed. Excessive use of router alert. Also a suggestion to change the layout of the document, but considered to late. Next step is to have a revised draft out real soon now. Does the WG want to do a new LC? Fred: What is the level of change? Elwyn: More than editorial, we need to add text on the disclaimer. Fred: We will do a new WG LC. o draft-ietf-v6ops-icmpv6-filtering-recs, Elwyn Davies IETF LC completed. Review at gen-art and sec-dir. Mostly editorial, but no recommendations for firewalls that are routers or bridges. Will be addressed and document will be sent back to the IESG. Firewalls that are routers and bridges will threat traffic differently and this should be addressed in the document. Text is updated and sent to the commenters, will be published shortly. Do we want a short WG LC? Fred: We will do a one week LC on this. o draft-ietf-v6ops-ipsec-tunnels, Pekka Savola Short update on document status. WG LC in aug 2005. Minor clean-ups done afterwards. Since last IETF review by Francis and we also solicited review by IP-Sec experts. We got one. Wanted to make sure that document didn't get issues with sec-dir review. Got two comments and both where related to tunnel mode IP-Sec. Proposed resolution is to remove all tunnel mode support, as there is no standards based solutions. Fred: Are you saying that future products should not support tunnel mode? Pekka: No, for configured IPv6 in IPv4 IP-Sec tunnels only support transport mode tunnels. Fred: Tunnel mode is in heavy use today. Pekka: ?? Francis Dupont: About tunnel mode, in fact that when you use transport mode you are using tunnel mode, difference is in policies. More and more things run transport mode instead of tunnel mode. Pekka: Are you supporting this way of resolving the issue? Francis: It's one way but it's drastic. Fred: It makes me really uncomfortable. I want to re-read the draft. Let's take this off-line. o draft-ietf-v6ops-802-16-deployment-scenarios, Myung-Ki Shin The goal of the draft is to give deployment scenarios of IPv6 in 802.16 broadband networks. WiMax have defined IP network models and interoperability. They are also working on IPv6 scenarios. Original draft was presented at IETF65. There is now a revised draft out, presented here. Draft discussed with 802.16 experts. Three of the scenarios where clarified based on this. Plan to update draft and then do a WG LC on the new version. Fred: Can I get 3 people to volunteer to review this? Jordi Palet, Alain Durand and Jonne Soininen volunteered. o draft-ietf-v6ops-routing-guidelines-00.txt, Mark Blanchet Draft was presented in Dallas and adopted as WG document. Based on comments received, terminology, TEREDO and wording on transit for 6to4, and registry BCP added in the new version. In the first version of the draft prefix length filtering was discussed but got rejected so removed. Then this was brought up again on the list. This was discussed on both the v6ops and the ARIN pplm list, and in some private discussions. The draft has some possible solutions. Recommend /48 filtering, but seems hard to get support for. Recommend /64 filtering seems safe but adds little value. Last option is to not mention any value. Small group of people met this week. This led to some new drafts being written. I am not sure where to go with it in this document though. Next step is to resolve the maximum prefix length filtering. There where also two comments on adding multicast and RPSL code. Will be added in the final draft and RPSL code added as example. Bernhard Tuhy: In my mind you should not say anything on the prefix-length filtering in the draft, this is a registry concern. Thomas Narthen: Let me disagree completely. Saying not to make a number at all makes a ??. At the last ARIN meeting there was a feeling that you are not allowed to deaggregate a /32, but there is a need for a BCP document that outlines that doing deaggregation for multihoming is needed. And that this is not an issue for RIRs. But the document needs buying in from a larger community. Fred: Let me summarize the private meeting. There is the question on what are we trying to solve with picking a number? This is being done anyway. Giving a magic number and saying "filter here" will not do much good with route flaps and growing tables on the opposite side. Marla and Fred will go off to document the trade-offs of doing PA style multihoming. The small group will get to review and then taken to the v6ops WG. ARIN is asking for advice to be given to to the RIRs. Pekka Savola: On what Thomas said is that the RIRs want the IETF seal of approval but the outcome might be different than what they expected. Kurtis: Alain: The IETF is not the network police, and we can't say anything on filtering policy. What we can do is say that these are the trade-offs. Fred: That is what we are writing. Thomas: We need a document that clear up some of the mythology and also removes the issue of deaggregation of PA prefixes. Some of this comes out of the IETF. Bernhard Aboba: We had an IAB recommendation to allocate /48s to all sites. Now are we are experiencing that this is a mistake. Keep that in mind. Marc: Thomas, can you suggest some text. Thomas: Sure, I would be happy to contribute. We should also realize that deaggregating doesn't necessarily mean that the routes have to go into the DFZ. Alain: I suggest that we go for option c) on the slides. Marla: Can you elaborate on why you think /48 is a mistake. Bernhard: This is a different question. Fred: Let's take that off-list. Thomas: Can I point people to draft-narten..... This revisits the /48 boundary. Please read and send comments, we want to send it to the IESG. Joe Abley: A side topic, there are RIR s that allocate /56 for critical infrastructure and those people are having issues with getting the routes to propagate. Iljitsch: The RIRs published a document that said you can filter on /32 and then they started giving out smaller allocations but not updating their documents. Thomas: The 2002 policy does not actually state what to filer on. But there might be words that can be interpreted that way. Jordi: Just to confirm what Joe said, there is only one RIR that currently allows PI, but there are thoughts to allocate all PIs out of a superblock. Not sure if that will be the same block if there are PI in other RIRs as well. Some recommendations are needed though. Joe Abley: I am not disagreeing with Jordi, but just to clarify, I wasn't talking about PI but critical infrastructure assignments. Fred: We will have to continue off-line. o draft-ietf-v6ops-addcon, Cipran H. - This draft aims to provide some guidance for doing an addressing plan. Split into enterprise considerations and provider considerations. - Changes made based on the WG feedback. Editorial changes, the write up of case-studies from Univ Southampton and T-Systems. Added a note on ULAs vs legacy site-local. PI space was not discussed as the policy is still under consideration. Added more details on anycast addresses, structure and usage. - Embedded-RP section was clarified. - T-Systems case-study goes through planning considerations for various roles of a provider. - Please review and comment. Fred: Any discussion? none. o draft-ietf-v6ops-scanning implications, Tim Chown - Documents different properties of IPv6 networks for network scanning. Suggest possible new attack vectors. - Comments made on the list are addressed, adopted as WG document and restructured. - Change made to avoid t suggesting that IPv6 subnet size makes networks resilient to scanning. - If you are running dual-stack you are also vulnerable for IPv4 scanning. - Goes through various alternatives for attackers to scan the address space, and various external factors that can give you a list of hosts. - Draft goes through measures that site admins can take to mitigate the scanning attacks. - It would be interesting to see from your firewalls what you are seeing in terms of scanning. We are only seeing portscanning for addresses that that advertised for example in MX records or web-servers. - Is this nearly ready for WG LC? There are three other docs that are related as well? Dave Thaler: Are the measures listed meant for an implementor or an admin? Tim: Both. Dave: Doc should split out what is for implementors and what is for site admins Peter Koch: From reading the document it seems to encourage the ostrich approach of hiding in the address-space. I am unhappy about the DNS parts especially as there are ways to enumerate the reverse address space. Tim: As for reverse DNS, there are certainly ways enumerate the reverse-space. Peter: If you really want to hide in address space, then you should hide BOTH forward and reverse DNS and perhaps use split-view DNS instead. Iljitsch: I have been thinking about this for a while, and this only goes that far. We won't see slammer like random propagation in IPv6, but for an attacker that is targeting your specific subnet, yes there is risk. Pekka: Peter made an excellent point, I think we have missed the reverse DNS issues. But OTOH personally I don't see that if you do stateless autoconf you don't want these addresses in the reverse DNS anyway, but it might be an issue for DHCP. Alain: I agree with Pekka. There are applicability ???? Same impression as with NAT document. It's good to say that we have a huge address space and you can do this do avoid scanning but?? Tim: Yes, address-planning can help you a bit. ???: There is a nice document in "login" from Steve Bellovin that goes through the scanning issues. Tim: Good point I will reference that. . There will be a new version addressing these issues and then a WG LC. o version independent TCP and UDP MIBs , Anders Person RFC4022 and 4113 have several objects with DESCRIPTION that are insufficient and can be implemented to behave in various ways. Dave Thaler: I can give some insight into what was intended. The details of what a process and and endpoint is was thought to be up to the endpoint. The intent was that a UDP endpoint in an implementation that uses UDP sockets, was a UDP socket. If you fork that would be a separate UDP endpoint. Ralf Drums: In some implementations when you fork there will still be a single socket. Dave: That is why I didn't want to use the word socket. I was just trying to say what the intent was. Ralf: Your argument is ok for UDP but not for TCP. Brian Haberman: The IESG was concerned with that the RFCs didn't have MIBs. We assumed that if there where issues with implementing this, the ops area would fix the MIBs and not do IPv6 specific fixes. Fred: Where should we take this? Brian: I suggest to the MIB mailinglist and then perhaps to the ADs. Dave Taler: ??? There have been work on the TCP MIB in some WG. Fred: Are any of your issues network layers or are they all TCP/UDP issues? Anders: Not really. Fred: Can the four of you talk and then take this to the transport area? Dave: The issues are good issues, and I can help clarify the intent but we should go to transport. Pekka: It's not that obvious to me if this is the right time to revise the MIB right now. For example the IP MIB is not yet implemented. Dave Thaler: There are some interest in working on these issues right now, and I encourage people to post to the mib list and then have a hallway discussion. Alain: There is some operational issues here, if these are unclear some of the vendors will implement the MIBs anyway, just different. It would be useful to have a document that listed what the issues are so that you can keep out for them. Fred: There is an internet draft, what more can we do? Brian: There is another way and that is to do an update for the RFC. o draft-arifumi-v6ops-addr-select-ps-00.txt Proposes a mechanism for providing policy distribution for prefix selection with DHCP. Focuses on a end-host that has multiple prefixes. User might encounter problems with address selection if there are multiple prefixes and a mixed environment of ULAs and global addresses for example. Multihoming is out of scope. The document lists a number of cases where RFC3484 but might not be enough, and gives suggestions of resolving. Do we want to this as WG document? Dave Thaler: I think this is useful and worth working on. But I don't think you want to include this in the 3484 for the multihoming case. Tim: I agree with Dave. I think this work should be taken forward. ??? Iljitsch: You said that there was no rule to select between a global address and a ULA address. If this is about src selection you could look at prefix length??? We should probably look at 3484 to add something about how to handle ULAs. There are discussions on changes to 3483 in shim6 as well. Fred: I hear there is interest but we need to coordinate with shim6 and dhc. Pekka: I would exclude dhc so far as we are still looking at the problem but have no solution. Tim: Some of us have this problem now and would like a solution. What is the status of the IPv6 WG work now? Kurtis: 3484 is being handled in the int-area. o draft-chown-campus-transition, Tim Chown This document started when v6ops was doing the scenarios documents and to compare the suitability for the enterprise scenario document. Second target was to look at the tools used for a transition. 4057 describes a number of steps for transition. The document goes through these steps and analyses them. Next steps is to see if there is WG interest? Fred: Is this useful? Elwyn: Is there any place where this would fit on the web? Could we just connect it off the v6ops web-site and not publish it? ???: I think that this document would deserve to be an informational RFC. It's useful for other campuses. o Benchmarking The benchmarking WG are working on IPv6. We are working on IPv6 issues and see a lot of interest. We wanted to take the issues to this WG as well and get review from operational experience. Link to document sent to the mailinglist, will send again. One of the major issues is extension headers. How should we deal with these and hop-by-hop in particular? One issue that has been pointed out is that the hop-by-hop header can have impact on the performance of routers. Should this header be included in the benchmarking? This is close to IP options in IPv4. o Other issues? None raised.