2.3.10 IP Version 6 Working Group (ipv6)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional IPv6 Page

Last Modified: 2005-06-27


Robert Hinden <bob.hinden@nokia.com>
Brian Haberman <brian@innovationslab.net>

Internet Area Director(s):

Mark Townsley <townsley@cisco.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://www.ietf.org/mail-archive/web/ipv6/index.html

Description of Working Group:

The IPv6 working group is responsible for the specification and
standardization of the Internet Protocol version 6 (IPv6). IPv6
a much larger global addresses space than its predecessor IPv4. This
enables global end-to-end communication and restores valuable
of the IP architecture that have been lost in the IPv4 Internet. The
IPv6 standards are widely implemented and are starting to see global

The IPv6 working group was originally chartered by the IESG as the IP
Next Generation (IPng) working group to implement the recommendations
the IPng Area Directors as outlined at the July 1994 IETF meeting and
"The Recommendation for the IP Next Generation Protocol," RFC1752,
January 1995.

The primary focus of the IPv6 w.g. is to complete the standardization
the IPv6 protocols, and to review and update the IPv6 specifications
based on implementation and deployment experience, and advancing them
the standardization track as appropriate.

The working group's work items are as follows:

o Complete Prefix Delegation requirements and publish. Related
  remaining work is:
- Develop Proxy Neighbor Discovery 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.
o Complete revision of IPv6 MIBs (combined IPv4/IPv6 versions) and
o Complete "Default Router Preferences, More-Specific Routes, and "Load
  Sharing" and publish.
o Update to ICMPv6 (RFC2463) and publish.
o Complete "Node Information Queries" and publish.
o Update Auto Configuration (RFC2462) and Neighbor Discovery (RFC2461)
  and publish.
o Investigate approaches to optimize or eliminate Duplicate Address
  Detection (DAD) to make reduce the delays incurred by DAD when there
  is a change of network attachment points. Publish a document defining
  DAD optimizations.
o Update "Privacy Extensions for Stateless Autoconfiguration" document
  (RFC3041) and publish.
o Complete work on IPv6 Node Requirements and publish.
o Complete work stemming from the working group decision to deprecate
  site-local addressing. This includes:
- Publish document deprecating the usage of Site-Local addressing.
- Publish revision of the IPv6 Address Architecture that includes
  the deprecation of site-local addressing.
- Publish a replacement for site-local addresses that removes the
  major limitations and allows for local allocations.
o Update the IPv6 Address Architecture to resolve the issues raised in
  the IAB response to the Robert Elz appeal and publish as a Draft
o Complete work on Scoped Addressing Architecture and publish.
o Update IPv6 over PPP (RFC2472) and publish.
o 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.
Done  Submit Site-Local Deprecation document to IESG for Informational.
Done  Submit Unique Local IPv6 Unicast Addresses to IESG for Proposed Standard
Done  Submit Link Scoped IPv6 Multicast Addresses to IESG for Proposed Standard
Done  Submit IPv6 Scoped Addressing Architecture to IESG for Proposed Standard
Done  Submit TCP MIB to IESG for Proposed Standard
Done  Submit Site-Local Deprecation document to IESG for Informational
Done  Submit Unique Local IPv6 Unicast Addresses to IESG for Proposed Standard
Done  Submit Router Preferences, More-Specific Routes to IESG for Proposed Standard
Done  Submit updates to Auto Configuration (RFC2462 to be republished at Draft Standard
Done  Submit update to ICMPv6 (RFC2463) to be republished at Draft Standard
Done  Submit Load Sharing to IESG for Proposed Standard
Done  Submit document defining DAD optimizations to the IESG for Proposed Standard
Done  Submit Update to Privacy Extensions for Stateless Autoconfiguration document (RFC3041) to the IESG for Draft Standard
Done  Submit update to IPv6 Address Architecture to the IESG for Draft Standard
Jul 05  Submit Proxy ND to IESG for Experimental
Jul 05  Resubmit Node Information Queries to IESG for Experimental status
Jul 05  Submit update to IPv6 over PPP (RFC2472) to IESG for Draft Standard
Jul 05  Submit updates to Neighbor Discovery (RFC2461) to be republished at Draft Standard
Nov 05  Re-charter or close working group.


  • draft-ietf-ipngwg-icmp-name-lookups-12.txt
  • draft-ietf-ipngwg-icmp-v3-07.txt
  • draft-ietf-ipv6-router-selection-07.txt
  • draft-ietf-ipv6-host-load-sharing-04.txt
  • draft-ietf-ipv6-link-scoped-mcast-09.txt
  • draft-ietf-ipv6-node-requirements-11.txt
  • draft-ietf-ipv6-rfc2096-update-07.txt
  • draft-ietf-ipv6-rfc2011-update-10.txt
  • draft-ietf-ipv6-unique-local-addr-09.txt
  • draft-ietf-ipv6-addr-arch-v4-04.txt
  • draft-ietf-ipv6-rfc2462bis-08.txt
  • draft-ietf-ipv6-optimistic-dad-05.txt
  • draft-ietf-ipv6-over-ppp-v2-02.txt
  • draft-ietf-ipv6-ula-central-01.txt
  • draft-ietf-ipv6-2461bis-04.txt
  • draft-ietf-ipv6-privacy-addrs-v2-04.txt
  • draft-ietf-ipv6-ra-mo-flags-01.txt
  • draft-ietf-ipv6-ndproxy-03.txt

    Request For Comments:

    RFC1883 PS Internet Protocol, Version 6 (IPv6) Specification
    RFC1884 PS IP Version 6 Addressing Architecture
    RFC1885 PS Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
    RFC1886 PS DNS Extensions to support IP version 6
    RFC1887 I An Architecture for IPv6 Unicast Address Allocation
    RFC1888 E OSI NSAPs and IPv6
    RFC1897 E IPv6 Testing Address Allocation
    RFC1970 PS Neighbor Discovery for IP Version 6 (IPv6)
    RFC1972 PS A Method for the Transmission of IPv6 Packets over Ethernet Networks
    RFC1981 PS Path MTU Discovery for IP version 6
    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
    RFC2450 I Proposed TLA and NLA Assignment Rules
    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
    RFC2460 DS Internet Protocol, Version 6 (IPv6) Specification
    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
    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
    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
    RFC3019 PS IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol
    RFC3041 PS Privacy Extensions for Stateless Address Autoconfiguration in IPv6
    RFC3122 PS Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification
    RFC3146 PS Transmission of IPv6 Packets over IEEE 1394 Networks
    RFC3178 I IPv6 multihoming support at site exit routers
    RFC3306 PS Unicast-Prefix-based IPv6 Multicast Addresses
    RFC3314 I Recommendations for IPv6 in 3GPP Standards
    RFC3316 I IPv6 for Some Second and Third Generation Cellular Hosts
    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 Bits of an IPv6 Address Block
    RFC3542 I Advanced Sockets Application Program Interface (API) for IPv6
    RFC3587 I IPv6 Global Unicast Address Format
    RFC3697 Standard IPv6 Flow Label Specification
    RFC3769 I Requirements for IPv6 prefix delegation
    RFC3879 Standard Deprecating Site Local Addresses
    RFC4007 Standard IPv6 Scoped Address Architecture
    RFC4022 Standard Management Information Base for the Transmission Control Protocol (TCP)
    RFC4087 Standard IP Tunnel MIB
    RFC4113 Standard Management Information Base for the User Datagram Protocol (UDP)

    Current Meeting Report

    Internet Protocol Version 6 WG (IPv6)
    Tuesday, August 2 at 1400-1600
    CHAIRS: Bob Hinden 
            Brian Haberman 
    1.  Document Status     (Haberman)
        Status on website:
    2.  Call for Implementation Reports     (Haberman)
        Chairs request submissions of implementation reports for
            - Privacy Extensions for Stateless Address Autoconfiguration in IPv6
            - IPv6 over PPP
        Implementation reports needed before specifications can be
        advanced to Draft Standard.
        RFC2472 update reports should include IPv6CP, Interface ID
        negotiation, and stateless autoconfig (over PPP).  
        RFC3041 to DS reports should include lifetime management and DAD
        on temporary addresses.
        Chairs will send out report templates to mailing list.
    3.  IPv6 Node Information Queries     (Haberman)
        Goal: Close open issues
        Node Information Queries: completed WG last call, some comments received.
        Intended to document what has been implemented, put as Experimental .
        Current use does not conform to RFC3307 regarding multicast prefix 
        The other open issue is restricting answering of queries to
        All-Hosts or All-Routers addresses  
        Pekka Savola: restricting queries is important if the hosts answer
        pings to those addresses.  Comment the issue wasn't specific to
        this ICMPv6 message.
        Asked if anyone disagreed with changing the prefix to conform to
        RFC3307?  Means existing implementations have to change and
        impact on current deployment.
        Haberman: people asking for the change are switch vendors who want
        to see it as local use multicast address  
        Bob Hinden: prefer keeping it as is since fairly widely deployed 
        Elwyn Davies: originally agreed with Bob, but can hit cases where
        nodes respond who weren't addressed ... interference with other
        multicast groups  
        Jinmei: as an implementor, doesn't mind changing
        Poll to change Multicast address.  About equal.  Chairs will take
        issue to the mailing list.
    4.  IPv6 Address Allocation to End Sites     (Narten)
        Goal: Discussion
        /64 is a fairly hard boundary.  Some RIRs want to allocate /56
        rather than /48s.   Consensus to make this a working group
        document. There is no consensus that this will be approved. 
        Brian Carpenter says IAB should be told that this WG is thinking
        about changing an IAB document. Some would rather they didn't know.
        Wide ranging discussion on the political aspects of the RIR
        boundaries, /64 boundaries, and the intentions behind changing the
        Reviewed history.  Today, sense that it is time to revisit/revise
        current policies based on experience gained since 1998  
        The /64 boundary is architectural.  Very costly to change, but
        space to left of 64 is policy managed.  The /48 is a policy
        Current RIR IPv6 policy: HD ratio of .8 used measures utilization,
        /48 to end sites, RIRs making large (/19) allocations to ISPs.
        How much space do we really have?  Should plan for space for 100
        years?  In 2050, /48 per person means 1/128 of space used.  Is
        this too much?
        Changing from liberal rules to conservative rules later has
        downsides, like we did in IPv4.
        ARIN proposed raising HD ratio to .94 .  May see a proposal to
        change /48 to /56 for SOHO at Oct 26 ARIN meeting.  Other RIRs
        also discussing   
        RFC3177 recommendations - A6 no longer in favor, GSE hooks
        superceded by multi6/shim6  
        RIRs view 3177 as IETF position on /48, would welcome IETF comment
        that /56 causes no architectural issues  
        ipv6-addr-arch-v4 states no boundaries other than 64 bit IID.
        Discussions about whether to go to /56 is in RIRs not in IETF  
        Document needs to document all relevant technical issues with /56
        vs /48  
        Alain Durand: did the WG make the wrong decision about /64
        boundary?  Should make sure future specs don't hard code 64
        assumption.  Thomas Narten: for things like CGA, more bits has
        technical value.
        Tony Hain: original policy was based on measuring hosts, whereas
        it should be networks so good to revisit.
        Thomas Narten: easiest is to just change HD ratio.  Discussion is
        on possibly doing /56 or not.  Changing /64 is off the table. 
        Tony Hain: Need to make sure 3177bis makes it clear that /64 to
        home is bad.
        Ralph Droms: what is impact of HD ratio change on operators?  does
        renumbering solve the problem?   
        Geoff Huston: .94 matches what we think is reasonable engineering
        Jim Bound: should accept as WG item 
        Jonne Soinenen: it's not just IETF docs that reference /64 but
        other communities like 3GPP, so it's very much fixed. 
        Ron Desorta: there's a consortium of RIRs which has a mailing list
        for this purpose, so that's the one place for the discussion (not 5-6) 
        Keith Moore: thinks it's a bad idea to change /48 recommendation.
        There are places that embed a /48 assumption, like 6to4. Thomas
        Narten: then the doc should talk about them.
        Keith Moore: disagrees that the doc should say the policy warrants
        revisiting.  Thomas Narten: doc does not recommend a change.  It's
        just to document the issues.  
        Poll taken to see if there is a consensus to adopt as a working
        group document.  There was a consensus is to adopt.
        Brian Carpenter: would be good for current IAB to comment, since
        RFC3177 is an IAB document.
    5.  URI Syntax     (Fenner)
        Goal: Make decision to adopt proposal
        Summarized the issues relating to how to represent scope in
        literal IPv6 addresses in URIs.  It's different from the site
        local issue since there's a specific grammar that makes it
        explicit there's a scope id  
        Doesn't want to use _ (underline) but not %.   Still need to
        choose replacement for _  
        Want to either move forward with this type of syntax with limited
        utility or else abandon the work.
        Greg Daley: might this be compatible with non URL use?   Bill
        Fenner: possible future path to accept this format outside URLs
        but not currently  
        Brian Haberman: Supports working on this, not worth effort to
        change the other spec.
        Keith Moore: should never use in production use in real
        applications, but fine with the doc.  Should have a statement
        saying use only for testing.  
        Bill Fenner: willing to accept document as working group item.  No
        objections.  Document adopted.
    6.  M and O Flags of IPv6 Router Advertisement     (Park)
        Goal: Resolve open issues with draft
        Draft defines host configuration behavior is for RFC3315 (DHCPv6)
        and information configuration behavior is for RFC3736 (stateless
          1) Ability to indicate to host that DHCP is not available.
          2) Ability to get all DHCP config with a single message exchange.
          3) Ability to do DHCP without having to configure routers.
        Hesham Soliman and Dave Thaler: why is the third one a
        Ted Lemon: get rid of acronyms HCB and ICB.
        Ralph Droms: should not use RFC numbers since they're overloaded.
        Ted Lemon: what if a rogue router sends RAs to deny service.
        Greg Daley: covered by the SEND RFC  
        Jinmei Tatyua: not recommending requirements just listing what
        have heard so far.  It's there to get around misconfigured
        Hesham Soliman: tries to be too intelligent, everything else is
        configured in the router anyway (prefix etc)  
        Brian Haberman: only situation we need to handle here is just if
        no prefix option.
        Bob Hinden: thinks only the first one is actually a requirement.
        Second one is an internal DHCP issue.  
        Jim Bound: not a lot of DHCPv6 clients out there, so not super
        painful to change something.  But lots of implementations of M
        and O so hard to mess with.  
        Iljitsch: are there any implementations that do something
        different with M or O?  
        Discussion will be continued on mailing list.
    7.  IPv6 over IEEE802.16     (Kim)
        Goal: New draft, Initial Discussion
        Service expected to be active within 1-2 years.  WMAN technology,
        uses standard IEEE MAC address.
        Transmission doesn't use MAC addresses, just 16 bit connection id
        since resources are scarce.
        L2 signaling protocol allocates CIDs to MAC pairs by a base
        Request folks to read draft and comment.  Not yet asking to become
        a WG doc, currently an individual document.  Authors encouraged to
        continue work and refine content and applicability. 
    8.  Network discovery and spoofing detection     (Pashby)
        Goal:  Introduction to drafts
        Presentation outlines several deployment issues with IPv6 in
        U.S. Navy test networks.  Drafts outline problems and puts forth
        straw man proposal for addressing.  Meant more to kick start
        discussion of the issues. 
        Proposed list of changes to ND 
        Send NAs to solicited node mcast addr, discard others, same for
        Christian Huitema: why not just do SEND instead? 
        Francis Dupont: do we need a huge change just to address spoofing? 
        Jim Bound: some countries are not comfortable with CGAs until IPR
        issues resolved  
        Erik Nordmark: how does Ron's proposed change help? 
        Brian Haberman: IDS's could detect spoofing since they can get the
        packets too.
        Erik Nordmark: could just changing the multicast MAC address then.
        Purpose is to discover all IPv6 addresses on a network.  Propose
        echo requests to a multicast address responded to after random wait.
        Encourage people to read docs and comment on list.  
        Chairs request discussion of the issues on the mailing list.
    9.  Distributing Default Address Selection Policy using DHCPv6 (Fujisaki)
        Goal:  Discussion
        Proposal for using DHCPv6 to distribute Address selection policy. 
        Issues raised with the validity of using DHCPv6 to do the work.
        Multi-homing and interface vs. node based policy identified as
        DHCPv6 option for policy table used in RFC 3484 (address selection
        http://www.nttv6.net/dass/ talks about policy table
        Dave Thaler: has problems with multihomed hosts, since this is a
        global table.
        Keith Moore: right, plus third parties are often naive and can
        cause problems.
        Ralph Droms: is it good to have control over this table is one
        question, whereas is DHCP the right way to configure is a
        different question.
        Ted Lemon: too hard to answer how to deal with multiple interfaces.
        Tatuya Jinmei: 3484 talks about app control over selection.
        Little support for this work.
    10. Next Steps for IPv6 w.g.     (Hinden)  
        Advancing core specification to Standard
        Goal: Discussion
        Since 1994 we have published 61 RFCs!  Core protocols went to
        Draft Standard in 1998.  Working group scheduled to close end of
        this year.
        Chairs recommend that the core protocols go to Full Standard and
        already meet the requirements as specified in RFC 2026.
        Proposed list of core protocols: 
           IPv6, Address Architecture, ICMPv6, Neighbor Discovery,
           Stateless Autoconfuration , and Path MTU Discovery.
        Possibly also Privacy Extensions, IPv6 over , and DNS.
        Chairs propose to not reopen Draft Standard RFCs, just recycle as is. 
        Some of the protocols are in the RFC-editors queue now, IESG could
        just approve as Full Standard  
        Proposal is similar to NEWTRK proposals to reduce steps in the
        standards process  
        Margaret Wasserman: in favor of this proposal.
        Keith Moore: thinks it doesn't qualified as Proposed Standard,
        since we haven't figured out to handle renumbering, or multiple
        addresses for a host.
        Margaret Wasserman: there were no problems when moving to Draft
        Keith Moore: recommend we should identify what the missing pieces
        Tony Li: we didn't solve those for IPv4, so should move RFC 791
        (IPv4 specification) to Experimental. 
        Ted Lemon: agree.
        List of RFCs to advance doesn't include APIs since those are
        Thomas Narten: would like to see fairly substantial deployment and
        usage.  Can we document production deployment or just testing? 
        Greg Daley: we're now seeing same attacks over IPv6 as we do over
        IPv4, so it's clearly production!
        Greg Daley: just let queued docs go to Draft without holding them
        Greg Daley question to Keith: is pointing shim6 sufficient?  
        Pekka Savola: Address arch isn't mature enough to advance yet, due to
        recent changes.
        Margaret Wasserman:  DNS is a draft standard.  Wants to move it
        forward as well.
        Chairs will put together concrete proposal and send to mailing


    IPv6 Introduction and Agenda
    Call for Implementation Reports
    ICMPv6 Node Information Queries
    IPv6 Address Allocation to End Sites
    URI Syntax of Scoped IPv6 Addresses
    IPv6 RA M & O bits
    IPv6 over IEEE 802.16
    IPv6 Network Discovery
    Spoofing Detection
    Distributing Address Selection Policy via DHCPv6
    Next Steps for IPvg W.G.