Corrections to the chairs.
Thanks, Bob and Brian
IPv6 Working Group Meeting Notes Seoul IETF Tuesday March 2, 2004, 1545 - 1800
Chairs: Robert Hinden <[EMAIL PROTECTED]> Brian Haberman <[EMAIL PROTECTED]> Minutes taken by Karen O'Donoghue <[EMAIL PROTECTED]> ------------------------------------------------------------------ Introduction and Agenda Bashing ------------------------------- Brian Haberman presented the proposed agenda. There were no comments, changes, or additions. Document Status --------------- Brian Haberman provided a link for document status to save time during the meeting. http://www.innovationslab.net/~brian/IETF59/IPv6/IPv6DocumentStatus.html Any questions or issues can be brought up at the end of the meeting or on the mailing list. Charter Update -------------- Bob Hinden stated that an updated charter and list of milestones have been forwarded to the IESG for review. This charter added work on Duplicate Address Detection, use cases for IPv6 flow label, and an update to the IPv6 address architecture (to resolve issues raised in the IAB response to Robert Elz appeal and deprecation of site-local addresses). Pekka Savola expressed a concern about the ipv6 working group being the right place to do the work on the use case for IPv6 flow label. Perhaps this work belongs in the diffserv working group. Bob Hinden pointed out that the diffserv co-chair (Brian Carpenter) had suggested adding the flow label work item to the ipv6 charter. The work needs to be done, and there currently isn't anyone else doing it. Node Requirements, John Loughney -------------------------------- * draft-ietf-ipv6-node-requirements-08.txt * Goal: IESG comments review This draft is currently in the hands of the IESG for review. There were a number of issues including EDNSO, Path MTU Discovery, and security. The EDNSO issue was rejected. The IESG (Steve Bellovin) thought path MTU discovery is a MUST. In fact, RFC 2460 strongly recommends that IPv6 nodes implement Path MTU discovery. The resolution of this issue is to quote from RFC 2460 to strengthen the MAY. There were two security issues: 1) the crypto algorithm requirements should be better aligned with recommendations from the IPsec WG, i.e. 3DES as SHOULD not MAY; and 2) IKEv? should be a SHOULD and not a MAY. A significant amount of discussion followed that basically addressed the rules for referencing RFCs and drafts in normative text. The relevant documents from the IPsec WG are drafts that in the words of Gregory Lebovitz are fully baked and should have been in IESG hands long ago. However, Bob Hinden indicated that he was nervous doing normative references to less mature (by definition) documents thus risking holding up this document. Margaret Wasserman indicated that there were a couple of different issues including that the purpose of this document is to state what IPv6 is and not what it should be. John Loughney proposed a resolution where these topics could be left out of the part of the document where we define IPv6. They could be moved from the security section to the security considerations section. Text could be written to indicate that the security drafts are good and you should consider them. The text would be informative, and the alert reader would know what to do. This avoids the issue of what normative text can reference. John agreed to provide some recommended text to forward to the IESG review in the next few weeks. 2461bis, Hesham Soliman ----------------------- * draft-soliman-ipv6-2461-bis-01.txt * Goal: status update The aim of this effort is to fix the bugs in RFC 2461 and recycle the document as a Draft Standard. Issues include mobility (5 unresolved), security (1 mostly resolved), and miscellaneous ND issues (9, 2 unresolved). For the mobility issues, some have been addressed in the mobile IPv6 specification and the dna wg is addressing some of them. Discussion indicated that issues 256 (random delay in RS) and 258 (random delay in NS) could be resolved with a clarification. In the area of security, all references to IPsec in message validation and message format sections were removed. A new section (paragraph) describes the applicability and limitations of using IPsec. There is some remaining text on IPsec in ND, but it is a bug and should have been removed. The question for the WG is what should the keyword be for SEND - MAY, SHOULD or MUST? SHOULD was recommended by one working group member. Discussion followed on how to proceed in the area of security. Erik Nordmark asked if we are going to hold this up for the referenced documents. Pekka Savola indicated that we don't need any uppercase keyword here. Margaret Wasserman didn't fully parse the plan. It is to take out all mention of IPsec and mention SEND where? Brian Haberman indicated the SEND text could in an appendix. Bob Hinden commented that if we can't point to anything stronger perhaps taking IPsec out wasn't such a smart idea. Margaret Wasserman stated that we shouldn't pull all security information out of document. However, if we keep IPsec it just has the appearance of being secure. Margaret Wasserman stated that we were letting bookkeeping get in the way of what we really want, what we want to say is use SEND. Bob Hinden stated that what we had before with IPsec isn't very useful. Thomas Narten suggested we should provide truth in advertising, tell them what should be done, use security considerations section, vrrp has precedent for taking security out, but you need to explain why to the IESG. Jim Kempf believes this is the example of an issue the standards track working group (newtrk) should address. Someone asked if we could go back to proposed standard. Bob Hinden doesn't want to go back to PS just to deal with normative reference issue. Finally, as a miscellaneous issue, Hesham Soliman brought up that 2461 is inconsistent with ADDRARCH because it allows the prefix length to be larger than 64 bits. Bob Hinden disagreed, the /64 requirement is not for all the address space. Erik Nordmark suggested incorporating Bob's statement into the document. Discussion and issue resolution on 2461bis will continue on the list. 2462bis, Tatuya Jinmei ---------------------- * draft-ietf-ipv6-rfc2462bis-00.txt * Goal: status update The issue tracker for 2462bis is located at https://rt.psg.com (user/passwd: ietf/ietf; queue ipv6-2462bis). There are 21 issues to date with 14 resolved, 2 needing confirmation, and 5 under discussion. The 2 issues needing confirmation are 271 (stable storage for autoconfigured addresses) and 274 (conflict between MLD spec and RFC2462). The suggested resolutions will be discussed further on the mailing list. The issue of the use of DHCPv6 was discussed. Greg Daley pointed out that DHCPv6 is at Proposed Standard and should not be used as a normative reference in a Draft Standard. Hesham Soliman pointed out that there are references to DHCPv6 in ND, so maybe it should come out of that document as well. Margaret Wasserman stated that she is unhappy with the fact that we aren't doing the right thing because of the process. This issue should be raised for the newtrk effort. The suggestion was made to move the language back to referencing "the stateful configuration protocol" where "stateful" equals DHCPv6. Tatuya Jinmei plans to move the rest of the issues to the list and to separate serious issues from future extensions. The plan is to revise the draft around the end of March hopefully receive consensus to move to WG last call. ICMPv6 Updates, Bob Hinden -------------------------- * draft-ietf-ipngwg-icmp-v3-03.txt * Goal: status update Mukesh Gupta has agreed to be editor. A new draft with changes is available. These changes include updates to rate limiting methods, 2 new codes for destination unreachable messages, revised security considerations, IANA considerations, and editorial changes. The primary open issue is the IANA considerations section, how new type and message codes should be assigned. Bob Hinden proposed to reserve a set of codes for private experimentation and to reserve type 255 for future expansion. IANA should register new type codes from IETF RFC publication requests. IETF WGs with WG consensus and AD approval can request reclaimable type code assignment from the IANA. Requests for type code assignments from outside the IETF should be sent to the IETF for review. Margaret Wasserman asked if this was trying to redefine existing IANA assignment levels. Thomas Narten pointed out that what Bob is proposing goes beyond the current RFC in this area. He also indicated that this is ok and is what the IANA considerations section should be used for. Thomas also indicated that we need to find the right balance between conserving the space and making this useful, should think carefully about code assignment outside the IETF, need to understand who has the authority to say yes or no to IANA, may be ok to publish but not to use ICMP code types. Bob Hinden stated that the next step is to turn this into text and issue a WG last call. Multi-protocol getnameinfo, Jun-ichiro -------------------------------------- * draft-itojun-ipv6-getnameinfo-multiproto-01.txt * Goal: Informational Jun-ichiro pointed out that getnameinfo() API needs to be fixed. He would like to gather comments here, publish an informational RFC, and send this document to the POSIX community. Bob Hinden asked if he wanted this to become a working group item or an individual effort. Jun-ichiro indicated that either way is ok by him. Bob Hinden directed the discussion to the list. Brian Haberman indicated he would also query the mailing list about whether or not to accept the address selection API as a working group item. Load Sharing, Dave Thaler ------------------------- * draft-ietf-ipv6-host-load-sharing-01.txt * Goal: status update. Ready for last call? The issue tracker is available at www.icir.org/dthaler/RouterSelectionIssues.htm. Dave Thaler feels this is ready for last call. The discussion was primarily focused on whether load balancing should be mandatory. Pekka Savola stated that making this type of load balancing a requirement is not a good idea. Operationally load balancing is only needed when you need the capacity. It is difficult to diagnose problems when load balancing is used. It seems we only have rough consensus that load balancing is a MUST. Bob Hinden indicated that we will do a WG last call and the issue can be raised there. NDProxy, Dave Thaler -------------------- * draft-thaler-ipv6-ndproxy-02.txt * Goal: WG last call? All issues from before the last IETF are closed. New technical issues include AH removal (#12), segments with different MTUs (#13), and IPv4 support (#10). Issue 12 was resolved by removing all mention of AH removal. For issue 13, it had originally been a non-goal to support segments with different MTUs. One of the two scenarios used actually have different MTUs. To resolve this issue, Dave removed references to modifying RAS. Finally, issue 10 addressed whether IPv4 support should be left in or removed. Options include: 1) leave IPv4 in with caveat; 2) remove all mention of IPv4; and 3) put IPv4 support in an appendix. After some discussion, the chairs polled the room. Approximately 8 people felt we should remove IPv4 support, and approximately 4 people felt we should keep it in. Thomas Narten observed that it was disappointing that there were so few opinions in the room. The chairs noted that since the working group didn't have a strong opinion, we should defer to the author. The conclusion was to do a WG last call on the document. Optimistic DAD, Soohong Daniel Park and Nick Moore -------------------------------------------------- * draft-moore-ipv6-optimistic-dad-04.txt * draft-park-dna-ipv6adopt-requirements-02.txt * Goal: Informational, adopt as part of new charter? Soohong Daniel Park summarized the requirements for optimistic DAD, and Nick Moore discussed the technical details. Optimistic DAD modifies behaviours defined in RFCs 2461 and 2462. It has been implemented as a patch to Linux 2.4.19, and a number of pathological cases have been tested. Optimistic DAD has been independently implemented by Ed Remmel of Elmic Systems. Discussion followed on the merits of this work. Robert Elz wondered if the approach might actually take longer than just doing DAD in some circumstances. This topic falls into a bigger picture with different groups inside and outside of the IETF working these link layer types of topics. Erik Nordmark asked how this would work with something like SEND. Hesham Soliman felt that even though there may be some really obscure corner cases, they shouldn't stop the effort. Dave Thaler expressed concerns about the interactions with SEND. Greg Daley commented that he did a fairly thorough look through of SEND and didn't find any show stoppers. Dave Thaler indicated that he felt there is a bunch of complexity that isn't worth it. Another individual stated that the complexity is worth it for real time applications. Brian Haberman asked the working group if we should adopt this document as a working group item. The consensus was yes. SIOCGIFaaa ioctls and IPv6 interfaces, Tatuya Jinmei ---------------------------------------------------- Network applications sometimes need a list of IP addresses on nodes, and there are problems in current APIs. This is a topic that is relevant to but not specific to IPv6. Is it sensible to discuss this type of issue in the IPv6 WG? Dave Thaler feels that the POSIX community is more appropriate. Bob Hinden suggested sending the request to the mailing list. --------------------------------------------------------- In closing the meeting, Bob Hinden mentioned the IPv6 demo on 36th floor. ------------------------------------------------------------------ Meeting Adjourned ------------------------------------------------------------------
