2.3.10 IP Version 6 Working Group (ipv6)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. 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-09-20


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 2005  Submit Proxy ND to IESG for Experimental
Jul 2005  Resubmit Node Information Queries to IESG for Experimental status
Jul 2005  Submit update to IPv6 over PPP (RFC2472) to IESG for Draft Standard
Jul 2005  Submit updates to Neighbor Discovery (RFC2461) to be republished at Draft Standard
Nov 2005  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-addr-arch-v4-04.txt
  • draft-ietf-ipv6-rfc2462bis-08.txt
  • draft-ietf-ipv6-optimistic-dad-06.txt
  • draft-ietf-ipv6-over-ppp-v2-02.txt
  • draft-ietf-ipv6-2461bis-05.txt
  • draft-ietf-ipv6-privacy-addrs-v2-04.txt
  • draft-ietf-ipv6-ra-mo-flags-01.txt
  • draft-ietf-ipv6-ndproxy-04.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)
    RFC4193 Standard Unique Local IPv6 Unicast Addresses

    Current Meeting Report

    IPv6 Working Group

    Vancouver IETF
    November 8, 2005

    Bob Hinden & Brian Haberman
    IPv6 w.g. chairs

    Minutes taken by Greg Daley, edited by Bob Hinden.


    • Introduction, Call for Scribes, and Agenda Bashing
      Haberman, 05 minutes
    • Document Status
      Haberman, 05 minutes
    • 8th TAHI Test Event, Miyata, 02 minutes
    • DOCSIS 3.0 and Stateless Autoconf, Droms, 10 minutes
      Goal: Raise Awareness
    • Considerations on M and O Flags of IPv6 Router Advertisement, Hinden, 15 minutes
      Goal: Consensus on document
    • IPv6 AdHoc Group Status report, Lindqvist, 10 minutes
      Goal: Status report
    • Advancing core specification to Standard, Hinden, 15 minutes
      Goal: Proposal and discussion
    • Future of IPv6 working group, Haberman, 10 minutes

    Introduction, Call for Scribes, and Agenda Bashing

    Chairs opened the meeting. Greg Daley agreed to take minutes. Reviewed agenda.

    Document Status, Haberman

    Document status is available at here at the IETF tools site.

    No questions.

    Also mentioned there will be a presentation in the L3VPN w.g. that the IPv6 w.g. was asked to review:

    It looked like this was trying to create a new kind of site-local addresses and a new class of global IPv6 addresses.

    Pekka Savola asked about status of the consensus call on ICMP name lookups.

    Brian: I've had some comments, and I want to incorporate the comments and get feedback.

    Question: In the document tracker, some comments on the (something) of DNS, have you made any progress on those?

    Brian: not yet.

    8th TAHI Test Event

    Another test event hosted by TAHI. With a new set of tests.

    Please make sure that you attend if you've got an implementation, and document the testing for implementation reports.

    DOCSIS 3.0 and Stateless Autoconf

    Alain Durand and I have been discussing 2462, i This has grown out of some work for cableworks for docsis. As we tried to integrate 2461/2 into docsis it wasn't clear how to do this. Fundamental problem is that addresses can come from lots of places.

    Prefixes can come from RAs and DHCPv6. Privacy extensions (different IIDs, same prefix).

    Local configuration: entire IPv6 address or just the IID, combined with an advertised prefix: like SAA, etc. How are these going to be combined on a host, how does the host choose. How does an ISP or IT department show hosts how to do this, and how does the department enforce policy.

    There may not be useful trust between hosts and network.

    Enforcement issues:

    RA can advertise M+O=0, but the host can try DHCPv6 anyway...
    Mutual trust... easy to enforce, DHCP server just does this anyway. Don't run a relay, or server.
    RA can advertise a prefix without A bit, hosts can do stateless with a prefix anyway.
    If an ID dept wants to enforce this: requires filtering at the edge.

    Not an administrator assigned address...

    If the network administrator wants to enforce that, then the DHCP address allocation must be used to control/inform filtering.

    What does the config mean when coming out of a router?

    Started this was RFC2462: there's no 2119 text.

    What does the config information mean: mandatory information, or indicative?

    If the config is mandatory, you can trust the device, but you still need to verify: source address filtering...

    Best you can get is that the best is advisory...

    M+O advisory. A bit off in RA:

    1. don't do SAA
    2. Don't do SAA even with RFC 3041(bis)
    3. Router is trying to enforce stateful address config, or is being used with a distributed (administered)IID, and the prefix is done using

    A bit set to false: Subtle problem:" no RFC 2119 precludes this.

    The text in there,


    Suresh: No text is defined how the behavior should be configured. No configuration variable named in the RFC. Ralph: There are other abstract variables Suresh: you could set policy (distribution) to turn off autoconf. 10 hosts on the link, and 2 don't autoconf. differential control of the devices on the link.

    Alain: quick response to the first point. some environments where going back to the router anyway won't be wasteful

    Thaler: bunch of original mechanisms... nothing can override static config. Filtering will be required regardless. Any time you don't use 2119, MUST is implied.

    Narten: If there's confusion then that's part of the whole document. People misinterpreting it isn't really a problem requiring revising the document. You're going to catch them with the filtering anyway.

    Dave Green: Information about filtering would you like something DHCPv6 server sending update rules to the firewall. Properly authenticated.

    Ralph: Come to DHC WG meeting this afternoon.

    Considerations on M and O Flags of IPv6 Router Advertisement

    Goal: Consensus on document

    M+O bits didn't reach a consensus last time. If we can't reach a consensus, then we have to do something, as it's not defined in the current Bis document.

    Referred from 2461 discussion. Changing the document may make 2461bis not a DS.

    A lot of discussion on the ML, the draft was doing too much, that it wasn't meeting the goals. Very little progress since last meeting. no new draft.

    3 requirements were proposed.

    1. Ability to indicate DHCP is not available,
    2. Ability to get everything with a single message exchange
    3. Ability to do DHCP without any routers.

    Consensus on 1 only.

    Thomas Narten proposed revised text for M+O on the mailing list:

    M : 
       1-bit "Managed address configuration" flag.  When set, it indicates
       that addresses are available via Dynamic Host Configuration Protocol
       [DHCPv6], including addresses that were not configured via stateless
       address autoconfiguration.  Clients SHOULD use DHC to obtain addresses
       (and associated configuration information) as described in [ADDRCONF].
       Note that when the M bit is set, the setting of the O bit is
       irrelevant, since the DHC server will return "other" configuration
       information together with addresses.
    O : 
       1-bit "Other configuration" flag.  When set, it indicates that
       [DHCPv6lite] is available for autoconfiguration of other (non-address)
       information.  Examples of such information are DNS-related information
       or information on other servers within the network. When set,
        - If the M bit is also set, clients SHOULD use DHC to obtain
          addresses (and associated configuration information) as described
        - If the M bit is not set, clients SHOULD use DHC as described in

    Proposal to WG:

    • Adopt this text.
    • Put new M&O text back into RFC2461bis
    • Drop this as a separate draft.


    Dave Thaler: Don't have any objection, need. Never want to use DHCPv6 only for addressing, but not for other information such as DNS. Want to make sure that M=>O.

    Thomas Narten: Who would make the decision not to use DHCP if there were some other information available. DT: want to make sure of that Thomas: DHCPv6 doesn't just give addresses. DT: Makes sense

    Suresh: 4th case: what does it mean if both bits not set. Need to add text saying M+O=0 means don't do DHCP.

    Bob Hinden: Could add a sentence after this. an indication of services,


    DHCPv6 protocol allows Server allowed to have options it won't send by default. O bit may be used to indicate non-default stuff that the host may request.

    Ralph: Don't think it's the intention Possible to send option request option to ask for this.

    No implication: no concept of that in the server.

    No way for the client to say it's getting stuff because of O-bit.

    Options that fit into that category, current spec only says whether

    Narten: keep it simple: ask for everything you may need.

    Ralph: Now understand Dave's question

    Dave: OK the implication is we'll ask for everything but addresses.

    It would be good to clarify that. We need to read the wording to make sure of that. No explicit description of option request option may be useful. That's basic DHCPv6.

    Ralph: Agree

    Alain: you say if M+O=0, then shouldn't bother...?

    SHOULD NOT request, unless you have a really good reason,

    Bob: listen to your routers.

    Alain: write this down:

    Jinmei: Comments on the text itself.

    This is an update on 2461...?

    Thomas: NSS.

    Update on 2461, but 2462 also describes this. Decided to remove text from 2462bis including when M+O bit changes on to off.

    When the host should do if there's no RA.

    There's some interesting discussion on this.

    2462 must assume M+O=on?

    if we adopt this proposal, what should we do with RFC 2462bis. We've simply removed the text

    Should we also revise RFC2462bis?

    One of the revised documents this should go into, and that both documents are in sync with each other. Better than doing a separate document. Document is it worth going in? doesn't matter which one maybe?

    Better to not do as a separate to make it a section in 2461bis, but make sure accords conceptual data structures

    Pekka: if M+O=0, hosts will want to try DHCP in any case, SHOULD NOT doesn't accord with existing reality.

    Thomas: Should recommend proper behavior.

    Thomas: Want people to not invoke DHCP, because it costs real bandwidth.

    JinMei: be sure: RFC 2461 bis add, revise RFC2462bis.

    Bob: Need to check 2462

    SHOULD may be too strong: M+O is availability of DHCP services.

    Basic consensus is that we should not use strong keywords... We need to confirm that sense to go with that text.

    Bob: Make sure this text is consistent with the rest? Have to go look again at document.

    Stig: DHCP client knows that in order to function, needs to be able to try DHCP ... Some preconfigured routers may not be possible Server on the same subnet here...

    Thomas/Bob: That's why it's should not must,

    Thomas: SHOULD --> MAY or we don't say anything at all? need clarity, want to make sure expectations are known.

    Special circumstances for specific devices.

    Don't encourage in general.

    Bob: Check in general. That the text is good to put back into 2461bis, and that the additional sentence is added? We'll need to check things in 2461 though...

    Feel of room call on that.

    Show of hands: quite a few.

    Jinmei: don't object to 2461 changes, but 2462 changes may be quite large, can't necessarily agree.

    Bob: it would surprise me if substantive change was required for 2462bis, and it would be a problem in that case. Need to check.

    IPv6 AdHoc Group Status report

    IAB adhoc groups, can create at any time (like directorate for IAB).

    Takes some IAB members and outside experts, formed to handle some issues around IPv6. Charters for these groups, and why they're here.

    Thomas stays in the group, but I'll chair group. Slide stolen off Thomas' slide in Minneapolis. IAB input forwarded to IANA.

    Work items group has discussed: 2 RFCs from the group. RFC 4147, 4159

    HD metrics draft-huston-hd-mteric-01.txt.

    Some of this discussion in the RIRs. Members going around to all RIRs.

    Talking about policies currently being used for allocations.

    Special purposes address book.

    IANA special purpose allocations, no specifications how to use this block. RIRs waiting for IAB.

    Have a proposal now, draft text to RIRs, general agreement of what to use addresses for... Will get posted Monday.


    Not sure I understand the goal with the IAB group. RIR topics discussed, why are we doing this in IETF?

    Hinden: This block is an IANA allocated block, not an RIR block. No address assignment for a protocol for example from RIR.

    What about 2001::/X is exhausted?

    Hinden: Current space is undefined, and the other blocks assigned to IETF: this is consistent with other allocation strategies.

    Thomas: lots of history. hard to debug. Anycast blocks, teredo prefixes, Where do we allocate this out of? Previously done informally. Unicast space is the territory of RIRs

    We talked about some of these issues, we can iterate on this further to make sure people agree and understand the basics.

    Advancing core specification to Standard

    Goal: Proposal and discussion

    IESG core protocols as standard... Widely implemented, and interoperating.

    How to demonstrate that significant implementation and interoperation has been gained.

    Margaret: have done homework. Nothing in specific required. Ask working group? if the WG agrees, goes to full standard.

    Bob: thought we had to do more work, like your approach better.

    Thomas: Need to make sure that I heard: Thought I heard we don't need to make a case.

    Margaret: Came with nothing? asked if we need a report. Answer: We need nothing.

    Brian C: IETF wide last call, if agreed to be nonsense by the community then that's OK..

    What are the core specs? are they mandatory to implement?

    Bob: No, just my idea, not based on the node requirements, etc

    Brian: no relation to Node Requirements document.

    Margaret: Documents go one at a time, even if on the same ballot. Anything on DS for full, Suggest, also try one IPv6 over foo documents.

    Alain: DNS (belongs to another WG) , no objection but belongs to them.

    Proposal to write IPv6 Status Report. Would contain:

    • Summary of implementations
      • Host OS, Routers, Switches, Mobile devices, Firewall, etc.
    • Applications support
      • Web, DNS, SSH, email, SIP, VoIP, Jabber, Network management, etc.
    • RIR Allocations
    • Backbone Routing
      • Routing tables, Routing protocols, etc.
    • DNS Deployments
      • Root servers, next level, etc.
    • Network Deployments
      • Commercial, Government, Research
    Not 1000 pages, a summary. Links to additional information. A catalog of things which are done. Talk about how long things have been in place, O/S support for a day/week/year/decade.

    Need volunteers to write this implementation report. People to help propose and collect information. If you know of something: tell us. If we've got a volunteer to write this. Point to public documentation of the network.

    Request for Volunteers

    Jordi: Collecting information about this for a long time, on the WWW and in a database...

    Some problems with IPv6 core standard... Bugs in 2460? we have some need to fix these...

    • Security overview for v6ops.
    • Most implementations don't allow overlapping fragments.
    • May need a little bit of refreshing, was some resistance in general.
    Significant problems in specs (in nodereqs). Most problems not serious enough to revise the spec. Worry about a lot of changes.

    Lots of things would change (personal view) not a good idea to do that with IPv4. Easiest thing is to not do this...

    Taking it to full standard with things that have known problems. Seems a bit stupid to put out...

    Pekka: agree with Elwyn, PS requires no known technical omissions. consensus in WG that an approach is valid.

    Concerned that IETF document will be used to collect marketing material for implementations?

    Bob: Is a fair question, not a draft, RFC etc.

    Pekka: not really worth putting too much effort

    Brian: an extended implementation report, perhaps.

    Thomas: Sympathize with elwyn, trade off covering known ambiguities, or fix bugs, and going forward.

    J??:Take look if there's any significant in the specs (set a short time frame) to fix.

    The report: informational as short summary, which points to a fuller report

    Bob: Not a marketing document

    J??: Put that in the draft "this is not a marketing doc..."

    Bob: Pooled room if you think this is a good way forward with this, raise hands (some hands). against (no hands I could see).

    Future of IPv6 working group

    Some discussion on address selection, updates needed to remove site local etc...

    IPv6 is going on everywhere as should be. No big-ticket items for IPv6 WG.

    This be the last face-to-face.

    WG not concluded until everything published as RFC. Mailing list as a discussion location for IPv6. Shepherding activities to go through.

    JAK: Proxy ND security. More general problem. Supportive of how to close down... Not sure how to proceed. Don't know how many people are. Wouldn't modify plans for the this item

    Hinden: Sounds like a security area thing??

    Margaret: Where do things go which would come to this group? No sweeping answers?

    Not going to start up another group for that. Going to take a while.

    Waiting for documents, mailing lists declaring IPv6 done. specific extensions and updates etc.

    Some WGs like SEND are small and work just on a specific target.

    There's a evolution of the tasks to the specific areas.

    We'll be doing the same AD evaluations of tasks some through new WGs, some identified in INT-AREA.

    Brian: Lots of things done in this group you'd never do in an internet area WG.

    Bob and Brian thanked the community for the work on IPv6 and specifically thanked all of the area directors who have help with this working group. These include Scott Bradner, Allison Mankin, Thomas Narten, Erik Nordmark, and Margaret Wasserman.

    Meeting Adjourned


    Agenda and Introduction
    TAHI Test Event Announcement
    DOCSIS 3.0 and Stateless Autoconfiguration
    M&O Flags in Router Advertisements
    IAB Ad hoc IPv6 Group
    Advancing Core Specifications to Full Standard
    Future of IPv6 Working Group