Last Modified: 2004-02-02
The IPv6 working group was originally chartered by the IESG as the IP Next Generation (IPng) working group to implement the recommendations of the IPng Area Directors as outlined at the July 1994 IETF meeting and in "The Recommendation for the IP Next Generation Protocol," RFC1752, January 1995.
The primary focus of the IPv6 w.g. is to complete the standardization of the IPv6 protocols.
The working group's responsibilities are:
- Completing work on the IPv6 working group documents as described below, and - Reviewing and updating IPv6 specifications based on implementation and deployment experience, and advancing them on the standardization track as appropriate.
The IPv6 working group's standardization responsibilities are divided into two areas: Urgent for Deployment, and Completing Current Work. Priority will be given to the first area. The work items in each priority area are as follows:
Urgent For Deployment - Complete Prefix Delegation requirements and publish. Related work is: o Work with the DHCPv6 working group to write a DHCPv6 option for IPv6 prefix delegation. o Develop Proxy Router Advertisement solution for prefix delegation and publish. This enables a simple site border router to re-advertise downstream a prefix it hears on its upstream link. The Multi-Link subnet work will be used as the basis for this. Note: General multi-link subnet work will be done elsewhere in the IETF. - Complete revision of IPv6 MIBs (combined IPv4/IPv6 versions) and publish.
Current Work - Complete work on "A Flexible method to manage the assignment of bits of an IPv6 address block". - Revise "Aggregatable Unicast Addresses" (RFC2374) to remove TLA/NLA/SLA terminology and publish. - Revise "Basic Sockets Extensions" (RFC2553) and publish. - Revise "Advanced Sockets API" (RFC2292) and publish. - Complete "Default Router Preferences, More-Specific Routes, and Load Sharing" and publish. - Update to ICMPv6 (RFC2463) and publish. - Complete "Node Information Queries" and publish. - Update Auto Configuration (RFC2462) and Neighbor Discovery (RFC2461) and publish. - Update "Privacy Extensions for Stateless Autoconfiguration" document (RFC3041) and publish. - Complete work on IPv6 Node Requirements and publish. - Complete work on Flow Label and publish. - Explore and document the issues with site-local addressing. Determine appropriate limitations on the use of site-local addresses, and document those limitations. - Complete work on Scoped Addressing Architecture and publish. - Update IPv6 over PPP (RFC2472) and publish (may be done in PPP Extension w.g.). - Review Point-to-point link support in IPv6 and decide if any IPv6 specifications need to be updated. - Complete work on "Link Scoped IPv6 Multicast Addresses" and publish.
All new work items not listed above require the approval of the working group and IESG before they will be taken on by the working group.
Done | Submit A Flexible method to manage the assignment of bits of an IPv6 address block to the IESG for Informational. | |
Done | Submit Flow Label specification to IESG for Proposed Standard. | |
Done | Submit Prefix Delegation requirements and submit to IESG for Informational. | |
Done | Revise Aggregatable Unicast Addresses (RFC2374) to remove TLA/NLA/SLA terminology. | |
Done | Draft on Proxy RA solution for prefix delegation. | |
Done | Submit IPv6 Node Requirements to IESG for Informational. | |
Oct 03 | Submit UDP MIB to IESG for Proposed Standard | |
Oct 03 | Submit Link Scoped IPv6 Multicast Addresses to IESG for Proposed Standard. | |
Oct 03 | Submit IPv6 Scoped Addressing Architecture to IESG for Proposed Standard | |
Oct 03 | Submit TCP MIB to IESG for Proposed Standard. | |
Oct 03 | Resubmit Node Information Queries to IESG for Proposed Standard. | |
Nov 03 | Submit Router Preferences, More-Specific Routes, and Load Sharing to IESG for Proposed Standard | |
Nov 03 | Submit Site-Local Deprecation document to IESG for Informational. | |
Nov 03 | Submit Unique Local IPv6 Unicast Addresses to IESG for Proposed Standard | |
Nov 03 | Submit Requirements for Local Addressing to IESG for Informational | |
Nov 03 | Submit update to ICMPv6 (RFC2463) to be republished at Draft Standard. | |
Nov 03 | Submit Update to Privacy Extensions for Stateless Autoconfiguration document (RFC3041) to the IESG for Draft Standard. | |
Dec 03 | Submit updates to Auto Configuration (RFC2462) and Neighbor Discovery (RFC2461) to be republished at Draft Standard. | |
Dec 03 | Submit Proxy RA to IESG for Proposed Standard. | |
Dec 03 | Submit update to IPv6 over PPP (RFC2472) to IESG for Draft Standard. | |
Jan 04 | Re-charter or close working group. |
RFC | Status | Title |
---|---|---|
RFC1887 | I | An Architecture for IPv6 Unicast Address Allocation |
RFC1883 | PS | Internet Protocol, Version 6 (IPv6) Specification |
RFC1885 | PS | Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) |
RFC1886 | PS | DNS Extensions to support IP version 6 |
RFC1884 | PS | IP Version 6 Addressing Architecture |
RFC1897 | E | IPv6 Testing Address Allocation |
RFC1981 | PS | Path MTU Discovery for IP version 6 |
RFC1888 | E | OSI NSAPs and IPv6 |
RFC1972 | PS | A Method for the Transmission of IPv6 Packets over Ethernet Networks |
RFC1970 | PS | Neighbor Discovery for IP Version 6 (IPv6) |
RFC2019 | PS | Transmission of IPv6 Packets Over FDDI |
RFC2023 | PS | IP Version 6 over PPP |
RFC2073 | PS | An IPv6 Provider-Based Unicast Address Format |
RFC2133 | I | Basic Socket Interface Extensions for IPv6 |
RFC2147 | PS | TCP and UDP over IPv6 Jumbograms |
RFC2292 | I | Advanced Sockets API for IPv6 |
RFC2373 | PS | IP Version 6 Addressing Architecture |
RFC2374 | PS | An IPv6 Aggregatable Global Unicast Address Format |
RFC2375 | I | IPv6 Multicast Address Assignments |
RFC2461 | DS | Neighbor Discovery for IP Version 6 (IPv6) |
RFC2462 | DS | IPv6 Stateless Address Autoconfiguration |
RFC2463 | DS | Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification |
RFC2464 | PS | Transmission of IPv6 Packets over Ethernet Networks |
RFC2460 | DS | Internet Protocol, Version 6 (IPv6) Specification |
RFC2452 | PS | IP Version 6 Management Information Base for the Transmission Control Protocol |
RFC2454 | PS | IP Version 6 Management Information Base for the User Datagram Protocol |
RFC2465 | PS | Management Information Base for IP Version 6: Textual Conventions and General Group |
RFC2466 | PS | Management Information Base for IP Version 6: ICMPv6 Group |
RFC2450 | I | Proposed TLA and NLA Assignment Rules |
RFC2467 | PS | Transmission of IPv6 Packets over FDDI Networks |
RFC2470 | PS | Transmission of IPv6 Packets over Token Ring Networks |
RFC2471 | E | IPv6 Testing Address Allocation |
RFC2472 | PS | IP Version 6 over PPP |
RFC2473 | PS | Generic Packet Tunneling in IPv6 Specification |
RFC2497 | PS | Transmission of IPv6 Packets over ARCnet Networks |
RFC2507 | PS | IP Header Compression |
RFC2526 | PS | Reserved IPv6 Subnet Anycast Addresses |
RFC2529 | PS | Transmission of IPv6 over IPv4 Domains without Explicit Tunnels |
RFC2553 | I | Basic Socket Interface Extensions for IPv6 |
RFC2675 | PS | IPv6 Jumbograms |
RFC2710 | PS | Multicast Listener Discovery (MLD) for IPv6 |
RFC2711 | PS | IPv6 Router Alert Option |
RFC2732 | PS | Format for Literal IPv6 Addresses in URL's |
RFC2874 | PS | DNS Extensions to Support IPv6 Address Aggregation and Renumbering |
RFC2894 | PS | Router Renumbering for IPv6 |
RFC2928 | I | Initial IPv6 Sub-TLA ID Assignments |
RFC3041 | PS | Privacy Extensions for Stateless Address Autoconfiguration in IPv6 |
RFC3019 | PS | IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol |
RFC3122 | PS | Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification |
RFC3178 | I | IPv6 multihoming support at site exit routers |
RFC3146 | PS | Transmission of IPv6 Packets over IEEE 1394 Networks |
RFC3306 | PS | Unicast-Prefix-based IPv6 Multicast Addresses |
RFC3314 | I | Recommendations for IPv6 in 3GPP Standards |
RFC3484 | PS | Default Address Selection for Internet Protocol version 6 (IPv6) |
RFC3493 | I | Basic Socket Interface Extensions for IPv6 |
RFC3513 | PS | IP Version 6 Addressing Architecture |
RFC3531 | I | A Flexible Method for Managing the Assignment of Bites of an IPv6 Address Block |
RFC3316 | I | IPv6 for Some Second and Third Generation Cellular Hosts |
RFC3542 | I | Advanced Sockets Application Program Interface (API) for IPv6 |
RFC3587 | I | IPv6 Global Unicast Address Format |
concludedIPv6 Working Group Meeting Notes Seoul IETF Tuesday March 2, 2004, 1545 - 1800 Chairs: Robert Hinden <bob.hinden@nokia.com> Brian Haberman <brian@innovationslab.net> Minutes taken by Karen O'Donoghue <odonoghuekf@nswc.navy.mil> ---------------------------------------- -------------------------- 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/IE TF59/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 ---------------------------------------- -------------------------- |