2.3.4 IP Version 6 Working Group (ipv6)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       http://playground.sun.com/pub/ipng/html/ipng-main.html -- Additional IPv6 Page
NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-02

Robert Hinden <bob.hinden@nokia.com>
Brian Haberman <brian@innovationslab.net>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret@thingmagic.com>
Internet Area Advisor:
Margaret Wasserman <margaret@thingmagic.com>
Mailing Lists:
General Discussion: ipv6@ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/ipv6
In Body: subscribe
Archive: http://www1.ietf.org/mail-archive/working-groups/ipv6/current/
Description of Working Group:
The IPv6 working group is responsible for the specification and standardization of the Internet Protocol version 6 (IPv6). IPv6 provides a much larger global addresses space than its predecessor IPv4. This enables global end-to-end communication and restores valuable properties of the IP architecture that have been lost in the IPv4 Internet. The core IPv6 standards are widely implemented and are in the early stages of global deployment.

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.

Goals and Milestones:
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.
  • - draft-ietf-ipngwg-icmp-v3-03.txt
  • - draft-ietf-ipv6-router-selection-03.txt
  • - draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt
  • - draft-ietf-ipv6-host-load-sharing-01.txt
  • - draft-ietf-ipv6-flow-label-09.txt
  • - draft-ietf-ipv6-node-requirements-08.txt
  • - draft-ietf-ipv6-rfc2096-update-07.txt
  • - draft-ietf-ipv6-rfc2012-update-06.txt
  • - draft-ietf-ipv6-rfc2011-update-07.txt
  • - draft-ietf-ipv6-rfc2013-update-02.txt
  • - draft-ietf-ipv6-prefix-delegation-requirement-03.txt
  • - draft-ietf-ipv6-scoping-arch-01.txt
  • - draft-ietf-ipv6-deprecate-site-local-02.txt
  • - draft-ietf-ipv6-unique-local-addr-03.txt
  • - draft-ietf-ipv6-addr-arch-v4-00.txt
  • - draft-ietf-ipv6-inet-tunnel-mib-00.txt
  • - draft-ietf-ipv6-rfc2462bis-00.txt
  • Request For Comments:
    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

    Current Meeting Report

    concludedIPv6 Working Group Meeting Notes
    Seoul IETF
    Tuesday March 2, 2004, 1545 - 1800
    Robert Hinden <bob.hinden@nokia.com>
    Brian Haberman <brian@innovationslab.net>
    Minutes taken by Karen O'Donoghue 
    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 
    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 
    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 
    * 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 
    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 
    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 
    (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
    * 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
    * Goal: status update.  Ready for last call?
    The issue tracker is available at
    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
    * 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 
    In closing the meeting, Bob Hinden mentioned the IPv6 demo on 36th floor.
    Meeting Adjourned


    IPv6 Node Requirements
    Neighbour Discovery updates (RFC2461bis)
    RFC2462 updates
    ICMPv6 Update
    Multi-protocol consideration of getnameinfo()
    Host-to-Router Load Sharing
    NDProxy Update
    IPv6 DAD Optimization Goals and Requirements
    Optimistic DAD
    API extension to get IP addresses