IPv6 Operations WG IETF55 Atlanta November 20 2002 Chairs: Jun-ichiro "Itojun" Hagino (itojun@iijlab.net) Margaret Wasserman and (mrw@windriver.com) Reported by: Shawn A. Routhier (sar@epilogue.com) As with most meetings this one started off with some agenda bashing and a brief description of the previous and current status. For this WG this included a description of an interim meeting and the current work items. The interim meeting was held to launch the new WG and to discuss the charter and goals of the new WG. The initial work items accepted by the WG include: transition mechanisms, the survey of IPv4 addresses within RFCs and the 3GPP and unmanaged scenarios. New work items can be accepted by the WG but will need to go through the standard WG process. * We then proceeded to status reports and discussions on the four deployment scenarios that are currently under investigation. These include: unmanaged networks, ISPs, enterprises and cellular networks. * Christian Huitema - Unmanaged Networks Team Team members: R. Austein, S. Satapati, C. Huitema, R. van der Pol draft-ietf-ngtrans-unmanscope-02.txt draft-huitema-ngtrans-unmaneval-01.txt This group held a productive interim meeting and has above two drafts that have not been renamed into the V6OPS WG. The scenarios document needs some final clean up and minor edits but they belive the draft is mostly complete with two open issues dealing with the privacy and interoperability requirements. The privacy issue deals with the amount of privacy supplied by the transition mechanisms. Christian presented two opinions. Opinion 1 insists that there should not be any "privacy regression" - that is people using IPv6 should have no less privacy than people using IPv4 and a NAT. Opinion 2 is that the current level of privacy is just a random by-product of using a NAT and as such should not be turned into a requirement. This opinion also holds that other items, such as cookies, will break privacy. The floor was then opened to the WG for discussion on this topic. The sense of the room seemed to be that the options should be listed without being made requirements. Points from the discussion included 1) NATs with dynamic addresses could be added as a more private option. 2) The privacy requirements are not independent of the application. Different applications may choose different tradeoffs and attempting to choose a single option for the entire network might not work. 3) This is not simply a technical area. The social and legal realms may have implications for this area. As those realms are also evolving trying to codify them might not be useful. 4) The question of making the tradeoff was raised - who makes it, as well as when and how. 5) There is a difference between using a different address frequently (changing your address) and simply using an address that isn't derived directly from your MAC address. The final point of discussion was how this information should be presented or in what draft it should be included. The options are (1) try and put all of the privacy issues into a single document or (2) have each of the documents include a description of their issues. The WG seems to like (2) more with the caveat that eventually we may move to having a single document - either one of the current ones or a separate one - that handles the specific privacy issues and concerns. The interoperability issue deals with how much IPv4 (-) IPv6 interoperability is required during the IPv4 to IPv6 transition. We could aim for either only local interoperability or for full compatibility. There seems to be some consensus that local compatibility is required. The questions seem to be whether an IPv4 node should be able to reach services supplied by an IPv6 node or if an IPv6 node should be able to reach an IPv4 node. The WG seemed to feel that the number of IPv6 only devices would be low enough that we needn't worry about them that much. However there was resistance to this point with comments about IPv6 only devices and devices with dual stacks that are not configured to use the IPv4 side of the stack. It was also pointed out that an answer to these questions would depend on the cost of the options as well as which end is which and what each node is trying to do (be a host or server etc). Christian then discussed the solutions document which is currently a work in progress. It includes four cases. The first case (A) was that of a dual stack node behind a NAT with an IPv4 only ISP. The document suggests using Teredo in this case, but there was no clear consensus in the meeting that we need or should try to solve this problem. There was also some discussion about whether Teredo might be an overly complicated solution that would not be deployed in the real world. This discussion was sent to the mailing list. The second case (B) was that of a dual stack router and ISP. The discussion for this case covered NAT-PT and there was good consensus that we need a better NAT-PT specification. Three specific points were: the need for a reserved mapping prefix in IPv6, the need for a reserved mapping for IPv6 to IPv4 addresses and the dropping of automatic translation within the DNS. The reserved mapping from IPv6 to IPv4 addresses would make it easier for an entity to determine that it was communicating with an IPv6 entity and should attempt to use a native IPv6 address. Dropping the automatic translation would allow dual stack nodes to make their own decision about which address to use. The discussion brought up two points. The first was to suggest that IPv6 only hosts shouldn't talk to IPv4 only hosts, if a node wishes to be able to talk to an IPv4 only host it should be dual stacked. The second was that the solutions were becoming too complex. The third case (C) was that of a dual stack gateway and a single stack ISP which was using IPv4. In this case the document suggests using 6to4. The fourth case (D) was that of a dual stack gateway and a single stack ISP which was using IPv6. The recommendations from Christian were as follow. The scenarios document is mostly read and should be sent along for WG review, The solutions document still needs some work and is not ready for review, however either it or some of the problems it describes should be accepted by the WG for further work. * Cleveland Mickles - ISP Team draft-mickles-v6ops-isp-cases-02.txt This group has been working on the scenarios document and had planned to have it updated prior to IETF55, however they didn't met that deadline. Several sections have been added and some sections reworked however several sections require more work. These sections include: internet exchange point, broadband Ethernet and infrastructure. They plan to submit another revision of the document by the end of the year and then to start work on the solutions document. One set of comments they received dealt with having too much information in some sections. They attempted to rectify this, but the consensus of those that had read the draft was that there was still too much detail. They had also received some comments that the draft should address multi-homing. In the meeting there was one comment that multi-homing is important but there were several voices against its inclusion. There was a suggestion that they should include a small amount of text or a pointer to text describing possible show stoppers. The decision was to wait until the draft is produced and the WG can examine it then decide if it should be adopted by the WG. * Yanick Pouffary - Enterprise Team draft-pouffary-v6ops-ent-v6net-01.txt This is a fairly new group and so the drat is not yet complete. In this document the design group attempts to specify the scope of the document and the goals and non-goals. One of the primary goals was to identify and provide guidelines and tools for the transition. The following covers some of the points Yanick made in her presentation, for all the points please see the slides. The document includes a definition of "enterprise". The group felt that this description needs more context. The design group assumes that the reasons and methods for adoption of IPv6 will vary across users. They attempt to specify some of the variables that will influence how the transition will occur in some cases these will be external business reasons. The draft defines six scenarios. These are not intended to cover all possible options but are intended to include most of the general ones. The WG is requested to contribute any major scenarios they feel are missing. The design group feels that enterprises will need to do an inventory and determine what software will be affected by the transition. The enterprise will also need to determine what software can be extended and what will need to be updated. There were several comments about getting more deployment experience - some of this is already in the document as several members of the design team are deployers. One suggestion was for producing two sets of documents. One would be a distilled consensus document. The other set would describe what various groups have already done and what problems and pitfalls they have encountered. A further suggestion was that getting reports from non-vendors would be especially useful and that it might be useful to get similar reports for the other classes (ISP, Cellular etc). While the meeting didn't decide to create a separate set of documents the chair requested deployment reports from anybody who has such experience. There was a comment that the draft had two many acronyms, which the meeting agreed with. There was also some questions about the layout of the draft. Finally the design group plans to put the solutions into a separate document. * Jonne Soininen Cellular Networks Team draft-ietf-v6ops-3gpp-cases-00.txt draft-wiljakka-3gpp-ipv6-transition-02.txt Jonne pointed out that this group started first and so is somewhat ahead of the other groups. The scenarios document is already a WG document. This document seems to be stable and does not require major changes, though there are a few editorial tweaks to be handled. There was a request for a dual stack IMS scenario which was deemed out of scope for the design group. The last set of changes to the analysis document were mostly editorial and there are still several items left to do. These include clarifying the use of static vs dynamic tunneling, documenting the NAT-PT vs NAT64 issues, removing an error in the IMS 1 scenario and changing the name of the document (to analysis document). They also plan to use the Thakur document as input for the analysis document but need to check with the authors first. Jonne also described the scenarios they have developed for the analysis document so far these are. Please see the document for a description of these scenarios. The small number of people that have read the scenarios document feel that it is stable and acceptable for it to go to last call. There didn't seem to be a large amount of interest in the analysis document but it has been accepted as a working group item. The design group is to be turned into an authors group. One of the major areas of discussion was NAT-PT. The group agrees that there are substantial problems with NAT-PT however it is unclear as to how we can proceed given our current charter. (Note: Alain Durand has written a, possibly expired, draft on some of the issues.) Some of the points made in the discussion are: 1) NAT can not be a general solution - it may work for some applications but other applications will need a more specific ALG. 2) NAT-PT may eventually disappear while NATv4 may be around for a while. If so we may need to rework NAT-PT to make it as good as, but no better than NATv4. 3) Perhaps we should get some operational experience about the tools we have to determine they are truly broken before we try to write yet another. 4) The major scenario in which IPv6 only needs to inter-operate with IPv4 only may be the end game. When we want to allow for the use of legacy systems and most of the net is IPv6 only. 5) Some functions, such as DNS, will need to be dual stacked and we may need to understand how they interact with IPv6 before we can go to IPv6 only. 6) George Tsirtsis, the author of the RFC, pointed out that NAT-PT was not meant as a general solution. As such one of the first steps in updating the document should be to determine in which cases NAT-PT is useful. 7) One of the scenarios in the cellular document may require NAT-PT. One of the ADs, Thomas Narten, stated that if NAT-PT is broken then it should either be fixed or tossed. There were several suggestions as to what we should do including that NAT-PT should be revised or at least have an applicability statement inserted. There is no consensus that it can be fixed especially for all things that might want to use it. The meeting agreed that we should ask the ADs to add updating NAT-PT to our charter. * The following item describes the status and open issues of one of the current work items. * Erik Nordmark - draft-ietf-ngtrans-mech-v2-01.txt (update to RFC2893) Erik raised several issues and there was a small amount of discussion on some of them, however most of the discussion has been directed to the mailing list. Erik will send a draft to the mailing list with a basic plan of updating the draft according to the edits that the WG can agree on. The following list describes the issues that Erik raised. Should we drop mentions of unidirectional tunnels? (No discussion.) Is 1280 a reasonable MTU for encapsulators without dynamic tunnel MTU discovery? In the discussion it appears that a slightly larger size would be useful for mobile IP - this size would be 1280 plus space for another header. Is 4400 a reasonable cap on dynamic tunnel MTU discovery? In the discussion it was pointed out that it doesn't seem necessary to have a limit unless decpsulators have a large physical interface MTU, however most discussion should occur on the mailing list. Any other concerns about reassembly buffer size? (No discussion.) The IPv4 native address group includes IPv4 mapped addresses as currently defined. Is this an issue that needs to be dealt with? (No discussion.) Any comments on ingress filtering? * The following two items are proposals for new work items. * Myung-Ki Shin - draft-shin-v6ops-application-transition-00.txt This is an attempt to give developers some guidelines when writing or modifying applications. The discussion was quite short. One point was that some of the assumptions may be incorrect for example some applications can't be dual stacked. Another point was that an effort such as this should get a broader view. There is an effort underway to move this into the application area where it can get the appropriate review. This effort has been ongoing and unsuccessful so far but may be working better now. The chairs are to talk to the ADs to determine how to move forward on this effort. * Pekka Savola - draft-savola-v6ops-6to4-security-00.txt The basic issue is that the 6to4 specification is terse on security considerations and that security checks can be difficult to implement if multiple automatic tunneling mechanisms are used in the same box. One specific issue that Pekka brought up was that of 6to4 relay spoofing, in which an attacker could pretend to be a relay and send packets to a 6to4 router. He supplied two possible patches: (1) relays should always use 192.88.99.0/24 (from rfc3068) as their source address and (2) limited distribution of more specific 6to4 routes. The discussion questioned if (1) would be effective and indicated that some sort of cryptographic relationship would be necessary. Christian Huitema mentioned that this was being investigated as part of Teredo and that they are considering some sort of three way handshake. However this is a DDOS problem and it may not be unsolvable. There was some other discussion which included the following points: the use of asymmetric routing may be a flaw in the model, the lack of capability of ingress routing is part of the problem, better tracing in ICMP would help and finally that the problem is difficult but could be solved. As the WG was running out of time this discussion was ended and moved to the mailing list. ** We finished with some comments by Harald Alvestrand about the transition from the IPNG WG to the V6OPS WG. Harald has also sent a note describing this transition to the mailing list, people interested in this issue should also consult that note. Over the summer the ADs responsible for IPv4 became concerned about the NGtrans effort. They were concerned that there was a growing complexity in the transition options that would present deployment difficulties. This led to discussions about re-chartering the WG with several options being discussed including re-chartering the WG and concluding the current WG and creating a new WG. The end result of these discussions was to charter a new group and close the old group. The new group starts with a narrow charter that may be expanded as necessary. Harald pointed out that while this narrow charter is designed to focus this particular work effort, it is not meant to stop other work. People who are interested in items that are not included in the charter of the WG are encouraged to work on them with the standard options available. These options include bringing the item back to the WG or IESG after more work to try and get it adopted by the WG, publishing it as Informational or Experimental within the IETF framework or possibly taking the work somewhere else. There was a brief (as we were already past time) discussion of this issue that became a discussion of general IESG/IETF issues. Two of these issues were the requirements for publication of a document and for allocation of a resource. Both of these are handled on a cases by case basis but there are some general rules. In the case of publishing a document the requirements are higher for those on the standards track than those that will are Informational or Experimental. In the case of resource allocation, such as protocol numbers, the requirements are based on the scarcity of the resources. For scarce resources, such as protocol numbers, a stable standards track document is required, less scarce resources may be allocated in an Experimental document or via IANA. (Editor's note: there was also some discussion about resource allocation at the Thursday night plenary.) Two possible problems with the current process were also mentioned. The first is that it is possible for and AD to stall documents and the second is that it is difficult for a WG to indicate that they believe an AD has erred. In conclusion Harald reminded the group that he (or the IESG if appropriate) needs to hear about things in order to try and fix any problems and he encouraged people to talk to him (or them) if you believe there is some sort of process problem.