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:

       Additional IPv6 Page

Last Modified: 2003-06-25

Chair(s):
Robert Hinden <bob.hinden@nokia.com>
Margaret Wasserman <mrw@windriver.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <mrw@windriver.com>
Internet Area Advisor:
Thomas Narten <narten@us.ibm.com>
Mailing Lists:
General Discussion: ipng@sunroof.eng.sun.com
To Subscribe: majordomo@sunroof.eng.sun.com
In Body: subscribe ipng
Archive: ftp://playground.sun.com/pub/ipng/mail-archive
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.
Mar 03  Submit Prefix Delegation requirements and submit to IESG for Informational.
Done  Revise Aggregatable Unicast Addresses (RFC2374) to remove TLA/NLA/SLA terminology.
Apr 03  Draft on Proxy RA solution for prefix delegation.
Apr 03  Submit update to ICMPv6 (RFC2463) to be republished at Draft Standard.
Apr 03  Submit TCP MIB to IESG for Proposed Standard.
Apr 03  Submit IPv6 Node Requirements to IESG for Informational.
May 03  Submit Routing Table MIB to IESG for Proposed Standard.
May 03  Resubmit Node Information Queries to IESG for Proposed Standard.
May 03  Submit UDP MIB to IESG for Proposed Standard.
Jun 03  Submit IP MIB to IESG for Proposed Standard.
Jun 03  Submit Router Preferences, More-Specific Routes, and Load Sharing to IESG for Proposed Standard
Jun 03  Submit updates to Auto Configuration (RFC2462) and Neighbor Discovery (RFC2461) to be republished at Draft Standard.
Jun 03  Submit Update to Privacy Extensions for Stateless Autoconfiguration document (RFC3041) to the IESG for Draft Standard.
Jul 03  Submit Proxy RA to IESG for Proposed Standard.
Jul 03  Submit Link Scoped IPv6 Multicast Addresses to IESG for Proposed Standard.
Aug 03  Submit IPv6 Scoped Addressing Architecture to IESG for Proposed Standard
Aug 03  Submit update to IPv6 over PPP (RFC2472) to IESG for Draft Standard.
Nov 03  Re-charter or close working group.
Internet-Drafts:
  • - draft-ietf-ipngwg-icmp-name-lookups-10.txt
  • - draft-ietf-ipngwg-icmp-v3-02.txt
  • - draft-ietf-ipv6-dns-discovery-07.txt
  • - draft-ietf-ipv6-router-selection-02.txt
  • - draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt
  • - draft-ietf-ipv6-flow-label-07.txt
  • - draft-ietf-ipv6-link-scoped-mcast-03.txt
  • - draft-ietf-ipv6-node-requirements-05.txt
  • - draft-ietf-ipv6-rfc2096-update-04.txt
  • - draft-ietf-ipv6-rfc2012-update-03.txt
  • - draft-ietf-ipv6-rfc2011-update-03.txt
  • - draft-ietf-ipv6-prefix-delegation-requirement-03.txt
  • - draft-ietf-ipv6-scoping-arch-00.txt
  • - draft-ietf-ipv6-deprecate-site-local-00.txt
  • - draft-ietf-ipv6-unique-local-addr-00.txt
  • Request For Comments:
    An Architecture for IPv6 Unicast Address Allocation (RFC 1887) (66066 bytes)
    Internet Protocol, Version 6 (IPv6) Specification (RFC 1883) (82089 bytes) obsoleted by RFC 2460
    Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) (RFC 1885) (32214 bytes) obsoleted by RFC 2463
    DNS Extensions to support IP version 6 (RFC 1886) (6424 bytes)
    IP Version 6 Addressing Architecture (RFC 1884) (37860 bytes) obsoleted by RFC 2373
    IPv6 Testing Address Allocation (RFC 1897) (6643 bytes) obsoleted by RFC 2471
    Path MTU Discovery for IP version 6 (RFC 1981) (34088 bytes)
    OSI NSAPs and IPv6 (RFC 1888) (36469 bytes)
    A Method for the Transmission of IPv6 Packets over Ethernet Networks (RFC 1972) (6353 bytes) obsoleted by RFC 2464
    Neighbor Discovery for IP Version 6 (IPv6) (RFC 1970) (197632 bytes) obsoleted by RFC 2461
    Transmission of IPv6 Packets Over FDDI (RFC 2019) (12344 bytes) obsoleted by RFC 2467
    IP Version 6 over PPP (RFC 2023) (20275 bytes) obsoleted by RFC 2472
    An IPv6 Provider-Based Unicast Address Format (RFC 2073) (15549 bytes) obsoleted by RFC 2374
    Basic Socket Interface Extensions for IPv6 (RFC 2133) (69737 bytes) obsoleted by RFC 2553
    TCP and UDP over IPv6 Jumbograms (RFC 2147) (6383 bytes) obsoleted by RFC 2675
    Advanced Sockets API for IPv6 (RFC 2292) (152077 bytes) obsoleted by RFC 3542
    IP Version 6 Addressing Architecture (RFC 2373) (52547 bytes) obsoleted by RFC 3513
    An IPv6 Aggregatable Global Unicast Address Format (RFC 2374) (25068 bytes) obsoleted by RFC 3587
    IPv6 Multicast Address Assignments (RFC 2375) (14356 bytes)
    Neighbor Discovery for IP Version 6 (IPv6) (RFC 2461) (222516 bytes)
    IPv6 Stateless Address Autoconfiguration (RFC 2462) (61210 bytes)
    Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification (RFC 2463) (34190 bytes)
    Transmission of IPv6 Packets over Ethernet Networks (RFC 2464) (12725 bytes)
    Internet Protocol, Version 6 (IPv6) Specification (RFC 2460) (85890 bytes)
    IP Version 6 Management Information Base for the Transmission Control Protocol (RFC 2452) (19070 bytes)
    IP Version 6 Management Information Base for the User Datagram Protocol (RFC 2454) (15858 bytes)
    Management Information Base for IP Version 6: Textual Conventions and General Group (RFC 2465) (77339 bytes)
    Management Information Base for IP Version 6: ICMPv6 Group (RFC 2466) (27547 bytes)
    Proposed TLA and NLA Assignment Rules (RFC 2450) (24484 bytes)
    Transmission of IPv6 Packets over FDDI Networks (RFC 2467) (16028 bytes)
    Transmission of IPv6 Packets over Token Ring Networks (RFC 2470) (21677 bytes)
    IPv6 Testing Address Allocation (RFC 2471) (7991 bytes)
    IP Version 6 over PPP (RFC 2472) (29696 bytes)
    Generic Packet Tunneling in IPv6 Specification (RFC 2473) (77956 bytes)
    Transmission of IPv6 Packets over ARCnet Networks (RFC 2497) (10304 bytes)
    IP Header Compression (RFC 2507) (106292 bytes)
    Reserved IPv6 Subnet Anycast Addresses (RFC 2526) (14555 bytes)
    Transmission of IPv6 over IPv4 Domains without Explicit Tunnels (RFC 2529) (21049 bytes)
    Basic Socket Interface Extensions for IPv6 (RFC 2553) (89215 bytes) obsoleted by RFC 3493
    IPv6 Jumbograms (RFC 2675) (17320 bytes)
    Multicast Listener Discovery (MLD) for IPv6 (RFC 2710) (46838 bytes)
    IPv6 Router Alert Option (RFC 2711) (11973 bytes)
    Format for Literal IPv6 Addresses in URL's (RFC 2732) (7984 bytes)
    DNS Extensions to Support IPv6 Address Aggregation and Renumbering (RFC 2874) (44204 bytes)
    Router Renumbering for IPv6 (RFC 2894) (69135 bytes)
    Initial IPv6 Sub-TLA ID Assignments (RFC 2928) (11882 bytes)
    Privacy Extensions for Stateless Address Autoconfiguration in IPv6 (RFC 3041) (44446 bytes)
    IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol (RFC 3019) (28293 bytes)
    Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification (RFC 3122) (40416 bytes)
    IPv6 multihoming support at site exit routers (RFC 3178) (24453 bytes)
    Transmission of IPv6 Packets over IEEE 1394 Networks (RFC 3146) (16569 bytes)
    Unicast-Prefix-based IPv6 Multicast Addresses (RFC 3306) (12713 bytes)
    Recommendations for IPv6 in 3GPP Standards (RFC 3314) (48168 bytes)
    Default Address Selection for Internet Protocol version 6 (IPv6) (RFC 3484) (55076 bytes)
    Basic Socket Interface Extensions for IPv6 (RFC 3493) (82570 bytes)
    IP Version 6 Addressing Architecture (RFC 3513) (53920 bytes)
    A Flexible Method for Managing the Assignment of Bites of an IPv6 Address Block (RFC 3531) (11314 bytes)
    IPv6 for Some Second and Third Generation Cellular Hosts (RFC 3316) (48741 bytes)
    Advanced Sockets Application Protocol Interface (API) for IPv6 (RFC 3542) (173028 bytes)
    IPv6 Global Unicast Address Format (RFC 3587) (8783 bytes)

    Current Meeting Report

    IPv6 WG Minutes 
    July 14 & 17, 2003
    IETF57 -- Vienna, Austria
    =========================
    
    CHAIRS:	Bob Hinden <hinden@iprg.nokia.com>
    	Margaret Wasserman <mrw@windriver.com> 
    
    Minutes taken by Margaret Wasserman and Bob Hinden.
    
    AGENDA:
    
    Monday July 14, 2003
    
       Introduction and Agenda Bashing -- Bob Hinden (5 min)
       Document Status and Priorities -- Bob Hinden (10 min)
       Open Issues with IPv6 Node Requirements -- John Loughney (15 min)
       Open Issues with IPv6 MIBs -- Brian Haberman (10 min)
       Open Issues with Prefix Delegation Requirements -- Shin Miyakawa (10 
    min)  
       Bridge-like Neighbor Discovery Proxies -- Dave Thaler (15 min)
       IPv6 Node Information Queries -- Bob Hinden (15 min)
       IPv6 Socket API for source address selection -- Samita 
    Chakrabarti (10 min) 
       Link Name and Sequence Options for IPv6 Neighbor Discovery -- Naiming
       Shen (5 min) 
    
    Thursday, July 17, 2003
    
       Introduction and Agenda Review -- Bob Hinden (5 min)
       Open Issues with Scoped Address Architecture -- Jinmei Tatuya (10 min)
       Requirements for Local Addressing:
       Local Addressing Requirements -- Tony Hain & Juha Wiljakka (20 min)
       General Discussion of Local Addressing Requirements -- Chairs (30 min) 
       Unique Local IPv6 Unicast Addresses -- Bob Hinden (20 min)
       Site-Local Deprecation Document Plan -- Christian Huitema (30 min) 
    
    
    ----------------------------------------
    ------------------------------
    
    Introduction and Agenda Bashing -- Bob Hinden
    
    ---------------------------------------------
    
    Bob Hinden announced an IPv6 Interoperability event in September in 
    Brussels.  For more information see:
    
       http://www.etsi.org/plugtests
    
    Reviewed the agenda.  Plan is to discuss short topics and normal 
    business today, and use Thursday primarily for local discussion topic.  
    There were no comments or changes to the agenda.
    
    
    Document Status and Priorities -- Bob Hinden
    
    --------------------------------------------
    
    Review of Charter Milestones
    
    Revised  Current  Description
    -------  -------  
    -----------------------------------------------------
    
    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. 
    Jul 03  Mar 03    Submit Prefix Delegation requirements and submit to IESG 
    for Informational. 
    Done              Revise Aggregatable Unicast Addresses (RFC2374) to 
    remove TLA/NLA/SLA terminology. 
    Done    Apr 03    Draft on Proxy RA solution for prefix delegation.
    Oct 03  Apr 03    Submit update to ICMPv6 (RFC2463) to be 
    republished at Draft Standard. 
    Jul 03  Apr 03    Submit TCP MIB to IESG for Proposed Standard.
    Aug 03  Apr 03    Submit IPv6 Node Requirements to IESG for 
    Informational. 
    Aug 03  May 03    Submit Forwarding Table MIB to IESG for Proposed 
    Standard. 
    Aug 03  May 03    Resubmit Node Information Queries to IESG for 
    Proposed Standard. 
    Sep 03  May 03    Submit UDP MIB to IESG for Proposed Standard.
    Aug 03  Jun 03    Submit IP MIB to IESG for Proposed Standard. 
    Oct 03  Jun 03    Submit Router Preferences, More-Specific Routes, and Load 
    Sharing to IESG for Proposed Standard 
    Dec 03  Jun 03    Submit updates to Auto Configuration (RFC2462) and 
    Neighbor Discovery (RFC2461) to be republished at Draft Standard. 
    Dec 03  Jun 03    Submit Update to Privacy Extensions for Stateless 
    Autoconfiguration document (RFC3041) to the IESG for Draft Standard. 
    Dec 03  Jul 03    Submit Proxy RA to IESG for Proposed Standard.
    Sep 03  Jul 03    Submit Link Scoped IPv6 Multicast Addresses to IESG for 
    Proposed Standard. 
    Aug 03            Submit IPv6 Scoped Addressing Architecture to IESG for 
    Proposed Standard 
    DROP?   Aug 03    Submit update to IPv6 over PPP (RFC2472) to IESG for
                      Draft Standard. 
    Jan 04  Nov 03    Re-charter or close working group.
    
    James Kempf asked if the Neighbor Discover changes are related to a 
    mobility draft on Friday.  Bob Hinden explained that we are making 
    updates for minor issues and hope to recycle at Draft Standard.  Major 
    changes or new features should be considered independently.
    
    Discussion of dropping PPP.  Alex Conta thinks that we should update it for 
    specific changes, which he will send to the list.
    
    Document Status
    
    Published & Approvals
     - RFC's Published
        o RFC 3316 "Internet Protocol Version 6 (IPv6) for Some Second and 
    Third Generation Cellular Hosts"  
        o RFC 3513 "Internet Protocol Version 6 (IPv6) Addressing 
    Architecture"  
        o RFC 3531 "A Flexible Method for Managing the Assignment of Bits of an 
    IPv6 Address Block"  
        o RFC 3542 "Advanced Sockets Application Protocol Interface (API) for 
    IPv6"   
     - IESG Approved 
        o "IPv6 Global Unicast Address Format"
    
    Flow Label
     - Editor: Jarno Rajahalme
     - Status: In IETF Last Call
     - Milestone: DONE
        o Submit for PS
     - Open Issues:
        o None
    
    Global Unicast Addresses
     - Editor: Bob Hinden
     - Status: IESG Approved
     - Milestone: DONE
        o Submit for Info
     - Open Issues: 
        o None
    
    Proxy RA
     - Editor:  Dave Thaler	
     - Status: New draft
     - Milestones:
        o Internet Draft - DONE
        o Submit to IESG for PS - JUL 03
           - Update Milestone to DEC 03
     - To be discussed in WG
    
    Prefix Delegation Requirements
     - Editor:  Shin Miyakawa
     - Status: New draft in w.g. last call
     - Milestone:  MAR 03
        o Submit for Info
        o Update Milestone to JUL 03
     - To be discussed in WG
    
    IPv6 MIBs -- TCP MIB 
     - Editor: Rajiv Raghunarayan
     - Status: In w.g. last call
     - Milestone: APR 03
        o Submit for PS
        o Update milestone to JUL 03
     - Open Issues:
        o To be discussed in WG
    
    IPv6 Node Requirements
     - Editor: John Loughney
     - Status: New draft in w.g. last call
     - Milestone: APR 03
        o Submit for Info
        o Update milestone to AUG 03
     - Open Issues:
        o To be discussed in WG
    
    IPv6 MIBs -- Forwarding Table 
     - Editor: Brian Haberman
     - Status: New draft in w.g. last call
     - Milestone: MAY 03
        o Re-submit for PS
     - Update milestone to Aug 03
     - Open Issues:
        o To be discussed in WG
    
    Node Information Queries
     - Editor: Matt Crawford
     - Status: New draft in w.g. last call
     - Milestone: MAY 03
        o Re-submit for PS
        o Update milestone to Aug 03
     - Open Issues:
        o To be discussed in WG
    
    IPv6 MIBs -- UDP MIB
     - Editor: John Flick
     - Status: Draft available after IETF
     - Milestone: MAY 03
        o Submit for PS
        o Update milestone to SEP 03
     - Open Issues:
        o N/A
    
    IPv6 MIBs -- IP MIB
     - Editor:  Shawn Routhier
     - Status: In W.G. last call
     - Milestone: JUN 03
        o Submit for PS
        o Update milestone to AUG 03
     - Open Issues: 
        o To be discussed in WG
    
    Default Router Preferences
     - Editor: Rich Draves
     - Status: AD Comments Received
     - Milestone: JUN 03
        o Submit to IESG for PS
        o Update milestone to OCT 03
     - Open Issues:
        o Split load balancing into separate document
    
    Link-Scoped Multicast
     - Editor: Jung-Soo Park
     - Status: WG Draft Available
     - Milestone: JUL 03
        o Submit for PS
        o Update milestone to AUG 03
     - Open Issues:
        o Ready for WG last call?
    
    Scoped Addressing Architecture
     - Editor: Jinmei Tatuya
     - Status: WG Draft Available
     - Milestone: AUG 03
        o Submit for PS
     - Open Issues:
        o To be discussed in WG
        o Ready for w.g. last call?
    
    Site-Local Limits
     - Editor: (Chairs)
     - Status:
        o WG consensus to deprecate site-local
        o Requirements and Local addressing drafts available
     - Milestone: None
        o Add milestones
     - Open Issues:
        o To be discussed in WG
    
    Work Not Started
     - ICMP Update
     - Autoconfiguration Update
     - Neighbor Discovery Update
     - Privacy Extensions Update
     - PPPv6 Update (Drop?)
     - IPv6 Addressing Architecture to DS
         o Add milestone  NOV 03
    
    
    Open Issues with IPv6 Node Requirements -- John Loughney
    
    --------------------------------------------------------
    
    
    http://www.ietf.org/internet-drafts/draf
    t-ietf-ipv6-node-requirements-04.txt
    
       (See slides)
    
    The document is currently in last call, and needs to be updated to   
    address 14 issues. 
    
    Bob Hinden suggested that the Path MTU issue might be better resolved by   
    referencing the recommendations in the Path MTU document as it is 
    covered   in detail there.  John Loughney agreed. 
    
    Nidhi Bhaskar mentioned that SSM is in last call and that it should be   
    referenced in this group.  She will send proposed text to the WG.  Bob   
    Hinden raised concern that we may not want to be dependent on SSM if it   is 
    still a draft.  Brian Haberman pointed out that it is already in the   
    IESG, so this may not be a problem.  Pekka Savola said that IPR 
    recently   found relating to SSM, so this may not be just trivial. 
    
    Hesham asked if we should change the name of the document to host   
    requirements, since we aren't including router requirements.  John   
    Loughney will work on some text for the introduction that makes this   
    clear, if it isn't there already.  Dave Thaler pointed out that we should   
    have a section labeled "router requirements" unless it lists all of the   
    router requirements. 
    
    Alex Conta raised the issue that if neither Path MTU or 
    fragmentation is   mandatory, you can run into problems.  Dave Thaler 
    pointed out that RFC   2460 requires that you support 
    fragmentation reassembly or that you send   "too big" message.  This isn't in 
    the Path MTU document.  There is a   difference between what is 
    required for hosts and routers in this regard.   Alex Conta agreed. 
    
    Rob Austein asked if there are DOCSIS devices that use MIBs but don't   
    support SNMP.  Margaret Wasserman pointed out that DOCSIS devices do   
    support SNMP.  Some discussion of the fact that while devices SHOULD be   
    manageable, SNMP is a MAY.  Rob agreed that this addressed his issue. 
    
    Dave Thaler raised issue about what we do when a normative reference is   
    obsoleted by a newer one.  Do we assume that the requirement will follow   
    forward to a successor?  If so, we could only include references for the   
    currently published version.  Christian suggested that we remove   
    references to anything that isn't published yet.  Bob Hinden and John   
    Loughney agreed that we should review current status and decide what make   
    sense in each case. 
    
    Alain Durand raised concern about the fact that we might not have any   
    requirement for DNS discovery in the host requirements if the DNSOP WG   
    doesn't move forward on it.  John Loughney pointed out that there is no   
    RFC, and no specific plan to have one.  Bob Hinden pointed out that we   
    will need to cycle this document in the future -- if we wait for each new   
    thing, there will always be another one.  John Loughney agreed.   
    
    
    
    Open Issues with IPv6 MIBs -- Brian Haberman 
    
    --------------------------------------------
    
    
    http://www.ietf.org/internet-drafts/draf
    t-ietf-ipv6-rfc2011-update-03.txt
    
    http://www.ietf.org/internet-drafts/draf
    t-ietf-ipv6-rfc2012-update-03.txt
    
    http://www.ietf.org/internet-drafts/draf
    t-ietf-ipv6-rfc2096-update-04.txt
    
       (See slides)
    
    No issues raised with proposed changes suggested in presentation. 
    Documents will be forwarded to IESG when new drafts are published.
    
    ACTION:  Submit to IESG for Proposed Standard when new MIB drafts are 
    published.  
    
    
    Open Issues with Prefix Delegation Requirements -- Shin Miyakawa
    
    ----------------------------------------
    ------------------------
    
    
    http://www.ietf.org/internet-drafts/draf
    t-ietf-ipv6-prefix-delegation-requirement-02.txt
    
       (See slides)
    
    Reviewed requirements.  
    
    Asked if it was ready to send to IESG.  
    
    Question raised about prefix lifetimes.  Inside vs. outside prefix 
    lifetimes.  Review minutes from previous IETF meetings.  Ralph Droms 
    checked draft and could be added.
    
    Margaret polled w.g. to see if we should cycle, or move ahead as is. 
    Consensus to not make this change.  Will make editorial changes and will be 
    submitted to IESG when new draft is out.
    
    ACTION:  Submit to the IESG for Informational when new Prefix 
    Delegation Requirements draft is published.
    
    
    Bridge-like Neighbor Discovery Proxies -- Dave Thaler
    
    -----------------------------------------------------
    
    
    http://www.ietf.org/internet-drafts/draf
    t-thaler-ipv6-ndproxy-00.txt
    
       (See slides)
    
    Reviewed draft.   
    
    Few questions to clarify how it works, relationship to SEND, does it  
    require listening to all multicast traffic. 
    
    Erik Nordmark:  Doesn't understand relationship to SEND.  Not sure which  
    problems are being solved. 
    
    Nordmark: Loop prevention and for devices not support spanning tree  
    protocol. Assuming one device does spanning tree.  A: Should be 
    possible  to handle non IEEE spanning tree capable media.  Q: Wants to 
    understand  what are the limits of this proposal.  Document needs to be 
    clearer. 
    
    Alain Durand: What happens to TTL? Answer: Nothing, bridges don't touch  
    TTL.  Does it work with LLMNR? Answer: yes, no problem. 
    
    Question would like to see how to do SEND on Proxies.  Proxy SEND is  
    first priority after SEND spec is done. 
    
    Margaret Wasserman: This isn't exactly prefix delegation.  A: Right.  
    Relationship to Zeroconf Routers: A: This group not meeting this week,  had 
    one BOF previously.  No agreement on Zeroconf routers BOF.  Would  like to 
    see work go forward. 
    
    Pekka:  Why is spanning tree needed, and as a consequence,   we need to be 
    very careful which kind of problems we want to solve if we   really, 
    really think we DO need spanning tree. 
    
    Question: Does every node see every other node.  A: Yes, full  
    reachability to every prefix to every other prefix.  
    
    
    
    IPv6 Node Information Queries -- Bob Hinden 
    
    ------------------------------------------- 
    
    
    http://www.ietf.org/internet-drafts/draf
    t-ietf-ipngwg-icmp-name-lookups-10.txt 
    
       (See slides) 
    
    Thomas Narten asked what is implement, and there were some answers.  KAME 
    doesn't implement IPv4 portions, but USAGI does. 
    
    Alain Durand commented on privacy handling.  When someone asks for a name at a 
    private address, you don't want to reveal permanent names or 
    addresses.  And, when you query a permanent address, you don't want to 
    return temporary names/addresses.  There is also a need not to expose 
    mapping between private addresses that might allow you to track what the 
    same user is doing over time. 
    
    Rob Austein mentioned that the applicability of scenarios where these 
    things are relevant are out-of-scope. 
    
    Discussion of removing IPv4 address query -- at least one 
    implementation includes it.  Alain Durand brought up question of whether we 
    should extend this to IPv4 transport.  Bob Hinden hadn't thought about it. 
    Alain claims that the only thing needed to make this run over IPv4 is to 
    reserve the ICMP code in the IPv4 space. 
    
    A new draft is needed.  Bob will propose text changes to the WG for the RFC 
    3041 changes.  After that is resolved, could we send it to the IESG? Pekka 
    suggested that the applicability statement won't stop people from using 
    this in other ways.  We should either severely limit this draft or 
    publish it as experimental.  Alain Durand and Itojun indicated that they 
    would like to see the work published, because it is useful for 
    debugging IPv6 networks. 
    
    CONSENSUS: The group believes that we should publish something along these 
    lines, because of existing implementations and usefulness. 
    
    CONSENSUS: We have consensus of the group to submit the draft, with the 
    changes that Bob has proposed to the IESG for PS.  Bob and Matt will 
    update the spec and circulate the changes for 
    discussion/approval by the WG. 
    
    
    
    IPv6 Socket API for source address selection -- Samita Chakrabarti
    
    ----------------------------------------
    --------------------------
    
    
    http://www.ietf.org/internet-drafts/draf
    t-chakrabarti-ipv6-addrselect-api-01.txt 
    
       (See slides)
    
    Quick overview followed by open issues, due to time constraints.
    
    Alain Durand raised questions about whether this API would be 
    consistent with other APIs underway elsewhere -- IPSEC APIs, etc.
    
    Brian Carpenter expressed a concern that this might never be used by 
    application programmers.  They won't understand it and don't want to work on 
    this level.  We need a different level of abstraction.  Thinks we need an 
    API at this level, as well as at a higher level for Java 
    programmers, etc.
    
    Pekka thinks that this is a good, precise API for low-level control. 
    Having a higher level API would be okay, too.
    
    Jinmei Tatuya has discussed this with KAME folks -- not clear if this is the 
    right balance between low-level control and abstraction.  Prefers 
    Francis Dupont's idea.
    
    Erik thinks that some of this complexity (public/private) might be good to 
    expose to developers, but perhaps not others (COA optimization). Doesn't 
    think that per-process level stuff works well because of libraries and 
    assumptions made by libraries, etc.
    
    Francis believes that this API is too low level.
    
    Chairs asked who had read the document -- some people have.
    
    QUESTION: Should we accept this as a WG work item?  The group was split 
    with majority for accepting.
    
    Thomas Narten asked why people did not want to accept.  Christian 
    Huitema  said that he does not think that we need an API at this level.
    
    The chairs called the question again (rough count was 13 to 5 for 
    accepting the document).  No clear consensus.  We need to get more people to 
    read the draft and develop an informed opinion. 
    
    
    
    Link Name and Sequence Options for IPv6 Neighbor Discovery -- Naiming Shen
    
    ----------------------------------------
    -----------------------------
    
    
    http://www.ietf.org/internet-drafts/draf
    t-shen-ipv6-nd-name-seq-options-01.txt
    
    Deferred to Thursday morning.
    
    
    Thursday, 0900-1130 (Hall F2)
    =============================   
    
    Introduction and Agenda Review -- Bob Hinden
    
    --------------------------------------------
    
    Bob presented the agenda.  There were no comments or changes.
    
    
    Link Name and Sequence Options for IPv6 Neighbor Discovery -- Naiming
    Shen (10 min) 
    
    ----------------------------------------
    -----------------------------
    
    
    http://www.ietf.org/internet-drafts/draf
    t-shen-ipv6-nd-name-seq-options-01.txt
    
       (See slides)
    
    Comments from Greg Daley.  Thinks that naming portion may be 
    interesting. Issue regarding what happens when the sequence numbers don't 
    get responded to?  Answer -- if you don't get a response, you send 
    another one.
    
    Erik Nordmark mentioned that there is a protocol called MZAP (defined in RFC 
    2776) that allows this type of functionality.  Dave Thaler confirmed that it 
    is defined for IPv6.  There may be some overlap.
    
    Bob Hinden asked w.g. if there was interest in perusing this work.
    
    Greg Daley:  Some interest in naming portion, but not in sequence 
    numbers. 
    
    Nordmark:  Something in multicast for names as well.  
    
    Not a great deal of interest in perusing as a working group item. 
    
    
    Open Issues with Scoped Address Architecture -- Jinmei Tatuya
    
    ----------------------------------------
    ---------------------
    
    
    http://www.ietf.org/internet-drafts/draf
    t-ietf-ipv6-scoping-arch-00.txt
    
       (See slides)
    
    Major change in this version of the draft is removal of unicast 
    site-local addresses.  No comments on the list.  One issue has been 
    raised regarding PIM, but has been resolved and will be handled in a 
    separate draft.  Authors believe draft is ready for w.g. last call. 
    
    Christian Huitema brought up issue of anycast addresses for service 
    discovery.  Says that these addresses will have the same type of scoping 
    requirements as multicast addresses.  So, he thinks that we may want to 
    specify a scope for anycast addresses.
    
    Itojun responding to Christian -- wrote Anycast Analysis draft.  Issue is 
    not about scoping, but about the propagation of an anycast route.  In what 
    region is your anycast route advertisement propagated.  Captured in 
    anycast analysis.
    
    Jinmei thinks that the anycast topic is out of scope for this 
    document.
    
    
    Tony Hain believes that this document is nowhere near ready for last call, 
    because it will just need to be updated in six months or less.
    
    Margaret Wasserman believes that we should complete this draft because of 
    the need to get link-local addresses specified as soon as possible.
    
    Brian Carpenter agrees that in .5 hours to six months, we will have a 
    local addressing architecture of some kind.  He thinks that this 
    document needs to stay "in limbo" until we figure out what to do with 
    local addressing.  Thinks that we need to coordinate with ABNF text 
    representation folks to make sure that we are in sync.
    
    Jinmei is open to idea that we'd add local addressing to this draft, but is 
    pushing for last call because there are no remaining technical issues in the 
    contents of this draft.
    
    Erik Nordmark indicated that he disagrees with the previous comments by 
    Tony and Brian.  He thinks that we need to document link local. There are a 
    lot of open architectural issues with local addressing that he hoped there 
    would be answered in the IAB meeting, but they weren't.  May take time to 
    sort out these issues.
    
    Itojun agrees with Erik, and disagrees with Tony and Brian.  We need to 
    publish this document as soon as possible.
    
    Christian suggested that we finish the discussion in this meeting before we 
    publish this document.  Margaret Wasserman pointed out that we haven't had a 
    last call yet.  General agreement that we won't manage to issue a last call 
    before the end of this meeting, anyway. 
    
    
    Requirements for Local Addressing
    ---------------------------------
    
    
    Local Addressing Requirements -- Tony Hain & Juha Wiljakka
    
    ----------------------------------------------------------
    
    
    http://www.ietf.org/internet-drafts/draf
    t-hain-ipv6-sitelocal-01.txt 
    http://www.ietf.org/intern
    et-drafts/draft-templin-lsareqts-00.txt
    
       (See slides)
    
    Presentation was done by Tony, Fred and Juha in unison.  Tony is 
    presenting, but represents shared view.
    
    On question of local<>global communication, Dave Thaler pointed out that 
    there another question about whether you should be able to 
    communicate between to different local networks (i.e. merger case).
    
    Margaret Wasserman pointed out that we might want to communicate 
    global<>local for network management and debugging, especially in 
    situations where you only know a local address.  So, we shouldn't forbid it, 
    even if we discourage it.
    
    Alain Durand pointed out that there is complexity of having local and 
    global addresses on the same system.  Tony agreed.  Alain: If you have 
    public PI space, would it fit all of the requirements?  Tony thinks that it 
    would meet most of the requirements, but thinks that this should be done in 
    parallel with PI, because local addressing has security benefits that a 
    single error can't expose the whole network.
    
    Erik was happy with terminology, but then lost him.  Thinks that there 
    isn't a single local range -- need multiple nested and overlapping local 
    ranges.  Tony says that this mechanism will support multiple local 
    ranges.  Erik says that it adds to complexity to have multiple local 
    ranges and need to pick between them.  Bob Hinden asked if this is 
    different from multiple addresses...  Erik said that choosing between 
    multiple global addresses is less critical, because if you pick the wrong 
    one it is less efficient but works.  With local addresses if the 
    application picks the wrong one, it may not work.
    
    Ralph Droms pointed out that any application of scoped addressing may 
    cause problems with address selection.  Also, heard a lot of 
    requirements, all followed by "and therefore we need scoped 
    addresses". Asked about scope of the WG -- are we chartered to work on PI 
    addresses? Margaret -- we need a charter update to include this work, but 
    the charter won't include working on a portable addressing scheme for the 
    Internet.  That work is happening elsewhere -- IAB, multi6.
    
    Rob Austein indicated that some of the requirements as stated miss 
    important intermediate steps.  For example, in the case of a printer for the 
    SOHO market, the requirement isn't local addresses per se, it's to avoid an 
    unnecessary tech support load for the printer manufacturer by making it 
    possible for a new printer to come up out of the box able to 
    communicate on the local network without being accessible from the 
    outside world.
    
    Brian Haberman: On question of whether we should have 
    global<>local communication, need to remember that 
    applications should not have to be aware of the scope of these 
    addresses.  So, that may have implications for whether of not we allow 
    global<>local communications.  Brian supports working on a combined 
    document, because it would be good to have one complete 
    requirements document in front of us, so that we could work on it. 
    
    
    Marc Blanchet thinks that globally-routable, 
    provider-independent, portable addressing is important, so we should work on 
    it here. Concerned that we can't work on it.  Margaret agreed that this is 
    important, but not that it should be pursued in the IPv6 WG.  Bob Hinden 
    pointed out that there is still a big research aspect to the question of 
    portable global addressing.  This is very complex, and includes 
    conflicting requirements.  Doesn't believe that this will happen soon and 
    that the IPv6 w.g. should not defer this work until or if a solution to 
    this problem is developed.
    
    Question for the authors about combining the drafts.  Are the authors in 
    favor?  Tony and Juha (speaking for Fred who previously confirmed by 
    email) both indicated that they do want to do this.  They were already 
    working on it, but didn't get it done before meeting.
    
    Tim Chown, would like to use local addresses on networks that will be 
    bigger than /48.  Tony: really more of a discussion for the 
    implementation section.
    
    Christian Huitema -- missing requirement.  You need to have different 
    ranges of filtering in an enterprise network.  There is no such thing as a 
    site.  Some things will be local to a division, some to a site, some to the 
    company, etc.  The solution needs to accommodate wide ranges of 
    topologies.  The filtering requirement cannot be met by the 
    addressing structure alone.
    
    Erik Nordmark pointed out that there will be a problem if the local 
    addresses require apps changes, because it will take a long time to get 
    consensus and deploy.  Pointed out that this group can identify 
    requirements and needs for portable addressing and send those to the IAB and 
    IESG.  Don't have to do the work here.  People think that they need an 
    RFC1918 replacement in IPv6 -- perhaps not a technical requirement, but 
    that doesn't mean it is unimportant.
    
    Alain Durand has a problem with the logic that we need to have 
    requirements for local addresses, so we need to have local addresses 
    because they meet the requirements.  Local addresses are just one 
    possible solution.  Portable addresses are another solution.  Each has 
    benefits and complexities.  This issue needs to be explored with the 
    registries.
    
    Thomas pointed out that we don't declare registry issues 
    out-of-scope. We need to figure out what we need and work with the 
    registries to do it.
    
    Jordi Palet is concerned about NAT with IPv6.  Whether or not we go with 
    this type of decision, we need to make it very clear that vendors must not 
    implement NAT in IPv6.
    
    Asked if group is interested in seeing these documents combined, so that we 
    can work towards a work item in this area.  Strong consensus that it would be 
    worthwhile to combine these documents and work forward from
    here.
    
    CONSENSUS:  Combine current local addressing requirements documents and 
    work forward from here. 
    
    
    Unique Local IPv6 Unicast Addresses -- Bob Hinden
    
    -------------------------------------------------
    
    http://www.ietf.org/internet-drafts/draf
    t-hinden-ipv6-global-local-addr-02.txt 
    
       (See slides)
    
    James Kempf likes this proposal.  But, what happens when these leak into the 
    Internet?  Bob recommends that there should be a /7 filter to keep them 
    from leaking, but nothing bad happens when they leak.  Not ambiguous like 
    site-local, so nothing bad happens.
    
    Brian Haberman pointed out that, unlike net 10 addresses, you can tell who 
    has this allocation, so you can trace them back.
    
    Itojun pointed out that you will need to run two-faced DNS to respond with 
    local addresses internally, but not externally.  Thomas Narten 
    responded that that isn't necessarily true.  Depending on what address 
    selection rules we have, this may work fine.  Rob agreed with Thomas and 
    said that this is just like the firewall case.  Itojun pointed out that he 
    doesn't want to see IPv6 NAT.
    
    Marc Blanchet wanted to know if the application people have reviewed this 
    proposal.  Marc thinks that this is a very good proposal, a "much better 
    site-local", but wants to know if if addresses concerns of 
    applications people.
    
    Alain Durand indicated that leaking local addresses in DNS will cause 
    problems with delays, etc.  Margaret pointed out that this may depend on 
    address selection rules.
    
    Erik Nordmark indicated that there is a difference between leaking local 
    addresses in the DNS for nodes that _only_ have a local address, because you 
    can't reach them anyway.  But, leaking locals for nodes that do have 
    globals could cause problems, especially for UDP apps.
    
    Christian Huitema suggested changing the address selection rules to 
    require a better match than 7-bits to ??
    
    Hesham indicated that we will need some type of split-DNS for these 
    addresses.
    
    Tim Chown commented on several situations where having local 
    connections inter-connected could be complex.  Bob suggested that at some 
    size, a network is much better off getting a sufficient number of global 
    addresses.
    
    Comment that we should prefer non-global addresses in default address 
    selection, because they are more stable.  Otherwise, you need magic in the 
    resolver that determines which non-global addresses are reachable.
    
    Rob Austein pointed out that if we have to treat these specially for 
    address selection rules, the cost goes up.  He also pointed out the need to 
    keep local addresses local via split DNS, because "if we are going to lie, we 
    should lie consistently".
    
    Thomas mentioned that it would be good if these addresses would work with 
    the current address selection rules.  Bob agreed, and said that we also 
    have the option (perhaps not a good one) of putting this in FECO::/10 for 
    those rules.  Tony Hain pointed out that we could include something about 
    this in requirements document.  Thomas agreed.  Tony pointed out that you 
    may want different default selection rules in different 
    environments.
    
    Comment that we need some sort of ICMP error message if the address isn't 
    reachable.  If addresses are just black-holed an applications will keep 
    using it with no indication that it isn't usable.
    
    Question on adopting as a WG document.  Is it appropriate without 
    requirements ready?
    
    Brian Carpenter pointed out that it is important enough to get this work 
    done, so we should not wait until requirements are done to accept this.
    
    Christian agreed.
    
    Called the question: Should we accept this as a WG work item?  Strong 
    consensus to accept the document.
    
    CONSENSUS:  Accept "Unique Local IPv6 Unicast Addresses" as a working 
    group item.
    
    
    Site-Local Deprecation Document Plan -- Christian Huitema
    
    ---------------------------------------------------------
    
       (See slides)
    
    Discussion of deprecation of FECO::/ prefix anycast addresses.  Can we 
    still use these?  These could be used as reserved global addresses, 
    because all sites are the same.
    
    Erik Nordmark asked clarifying question about whether these addresses 
    would be used for finding local services (and be filtered at 
    boundaries) or for finding global services (which would require global host 
    routes). 
    
    Pekka Savola thinks that we should deprecate the FECO::/ anycast 
    addresses with the FECO::/ prefix.
    
    Margaret Wasserman suggested that the anycast addresses in the FCOO::/ 
    could be a replacement.  Christian said that he doesn't want to argue 
    about solutions, just the requirement for replacements.
    
    Dave Thaler pointed out that the real issue is the ability to 
    allocated hard-coded anycast addresses to reach services.  Can't be 
    computed based on addressing, needs to be completely hard-coded.
    
    Thomas Narten pointed out that we haven't fleshed out the anycast 
    architecture well enough.  Some things in the v6 spec and some things in the 
    anycast document are at odds with each other.
    
    Brian Carpenter would like to generalize the question.  Is it a 
    requirement that this document says something in particular with 
    backwards compatibility with legacy applications using FECO::/.
    
    Erik wants to make sure that the concern about applications needing to deal 
    with multiple addresses as part of this document.  Christian indicated that 
    the specific site-local problem is not with applications handling 
    multiple addresses, but is specifically about applications handling 
    scope.
    
    Ralph Droms think that we need to be clear about what the document is 
    documenting.  Christian indicated that it is documenting the FECO::/10 
    prefix.  Ralph wants to make sure that, when we come around again, we 
    aren't in the same place we were before we deprecated these 
    addresses.
    
    Rob Austein thinks that the address selection rules should be 
    discussed as a source of complexity and something that should be 
    evaluated for future solutions.
    
    CONSENSUS: Consensus of the group to adopt the first version 
    Site-Local Deprecation Document Plan document as a working group item.
    
    ---------------------------------
    Meeting Adjourned 
    ---------------------------------
    

    Slides

    Agenda
    Link Name and Sequence Option For IPv6 Neighbor Discovery
    IPv6 Node Information Queries Update
    Unique Local IPv6 Unicast Addresses
    IPv6 Node Requirements
    IPv4/IPv6 IP, TCP, & Forwarding MIB Issues
    IPv6 Socket API for Source Address Selection
    Updates/ Issues/ Next steps on the IPv6 Scoped Address Architecture