2.3.5 IP Version 6 Working Group (ipv6)


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

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

Last Modified: 2003-10-24

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

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

The primary focus of the IPv6 w.g. is to complete the standardization of the IPv6 protocols.

The working group's responsibilities are:

- Completing work on the IPv6 working group documents as described below, and - Reviewing and updating IPv6 specifications based on implementation and deployment experience, and advancing them on the standardization track as appropriate.

The IPv6 working group's standardization responsibilities are divided into two areas: Urgent for Deployment, and Completing Current Work. Priority will be given to the first area. The work items in each priority area are as follows:

Urgent For Deployment - Complete Prefix Delegation requirements and publish. Related work is: o Work with the DHCPv6 working group to write a DHCPv6 option for IPv6 prefix delegation. o Develop Proxy Router Advertisement solution for prefix delegation and publish. This enables a simple site border router to re-advertise downstream a prefix it hears on its upstream link. The Multi-Link subnet work will be used as the basis for this. Note: General multi-link subnet work will be done elsewhere in the IETF. - Complete revision of IPv6 MIBs (combined IPv4/IPv6 versions) and publish.

Current Work - Complete work on "A Flexible method to manage the assignment of bits of an IPv6 address block". - Revise "Aggregatable Unicast Addresses" (RFC2374) to remove TLA/NLA/SLA terminology and publish. - Revise "Basic Sockets Extensions" (RFC2553) and publish. - Revise "Advanced Sockets API" (RFC2292) and publish. - Complete "Default Router Preferences, More-Specific Routes, and Load Sharing" and publish. - Update to ICMPv6 (RFC2463) and publish. - Complete "Node Information Queries" and publish. - Update Auto Configuration (RFC2462) and Neighbor Discovery (RFC2461) and publish. - Update "Privacy Extensions for Stateless Autoconfiguration" document (RFC3041) and publish. - Complete work on IPv6 Node Requirements and publish. - Complete work on Flow Label and publish. - Explore and document the issues with site-local addressing. Determine appropriate limitations on the use of site-local addresses, and document those limitations. - Complete work on Scoped Addressing Architecture and publish. - Update IPv6 over PPP (RFC2472) and publish (may be done in PPP Extension w.g.). - Review Point-to-point link support in IPv6 and decide if any IPv6 specifications need to be updated. - Complete work on "Link Scoped IPv6 Multicast Addresses" and publish.

All new work items not listed above require the approval of the working group and IESG before they will be taken on by the working group.

Goals and Milestones:
Done  Submit A Flexible method to manage the assignment of bits of an IPv6 address block to the IESG for Informational.
Done  Submit Flow Label specification to IESG for Proposed Standard.
Done  Submit Prefix Delegation requirements and submit to IESG for Informational.
Done  Revise Aggregatable Unicast Addresses (RFC2374) to remove TLA/NLA/SLA terminology.
Done  Draft on Proxy RA solution for prefix delegation.
Done  Submit IPv6 Node Requirements to IESG for Informational.
Oct 03  Submit UDP MIB to IESG for Proposed Standard
Oct 03  Submit Link Scoped IPv6 Multicast Addresses to IESG for Proposed Standard.
Oct 03  Submit IPv6 Scoped Addressing Architecture to IESG for Proposed Standard
Oct 03  Submit TCP MIB to IESG for Proposed Standard.
Oct 03  Resubmit Node Information Queries to IESG for Proposed Standard.
Nov 03  Submit Router Preferences, More-Specific Routes, and Load Sharing to IESG for Proposed Standard
Nov 03  Submit Site-Local Deprecation document to IESG for Informational.
Nov 03  Submit Unique Local IPv6 Unicast Addresses to IESG for Proposed Standard
Nov 03  Submit Requirements for Local Addressing to IESG for Informational
Nov 03  Submit update to ICMPv6 (RFC2463) to be republished at Draft Standard.
Nov 03  Submit Update to Privacy Extensions for Stateless Autoconfiguration document (RFC3041) to the IESG for Draft Standard.
Dec 03  Submit updates to Auto Configuration (RFC2462) and Neighbor Discovery (RFC2461) to be republished at Draft Standard.
Dec 03  Submit Proxy RA to IESG for Proposed Standard.
Dec 03  Submit update to IPv6 over PPP (RFC2472) to IESG for Draft Standard.
Jan 04  Re-charter or close working group.
Internet-Drafts:
  • - draft-ietf-ipngwg-icmp-name-lookups-10.txt
  • - draft-ietf-ipngwg-icmp-v3-02.txt
  • - draft-ietf-ipv6-router-selection-02.txt
  • - draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt
  • - draft-ietf-ipv6-flow-label-08.txt
  • - draft-ietf-ipv6-link-scoped-mcast-03.txt
  • - draft-ietf-ipv6-node-requirements-06.txt
  • - draft-ietf-ipv6-rfc2096-update-05.txt
  • - draft-ietf-ipv6-rfc2012-update-04.txt
  • - draft-ietf-ipv6-rfc2011-update-04.txt
  • - draft-ietf-ipv6-prefix-delegation-requirement-03.txt
  • - draft-ietf-ipv6-scoping-arch-00.txt
  • - draft-ietf-ipv6-deprecate-site-local-01.txt
  • - draft-ietf-ipv6-unique-local-addr-01.txt
  • - draft-ietf-ipv6-addr-arch-v4-00.txt
  • Request For Comments:
    RFCStatusTitle
    RFC1887 I An Architecture for IPv6 Unicast Address Allocation
    RFC1883 PS Internet Protocol, Version 6 (IPv6) Specification
    RFC1885 PS Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
    RFC1886 PS DNS Extensions to support IP version 6
    RFC1884 PS IP Version 6 Addressing Architecture
    RFC1897 E IPv6 Testing Address Allocation
    RFC1981 PS Path MTU Discovery for IP version 6
    RFC1888 E OSI NSAPs and IPv6
    RFC1972 PS A Method for the Transmission of IPv6 Packets over Ethernet Networks
    RFC1970 PS Neighbor Discovery for IP Version 6 (IPv6)
    RFC2019 PS Transmission of IPv6 Packets Over FDDI
    RFC2023 PS IP Version 6 over PPP
    RFC2073 PS An IPv6 Provider-Based Unicast Address Format
    RFC2133 I Basic Socket Interface Extensions for IPv6
    RFC2147 PS TCP and UDP over IPv6 Jumbograms
    RFC2292 I Advanced Sockets API for IPv6
    RFC2373 PS IP Version 6 Addressing Architecture
    RFC2374 PS An IPv6 Aggregatable Global Unicast Address Format
    RFC2375 I IPv6 Multicast Address Assignments
    RFC2461 DS Neighbor Discovery for IP Version 6 (IPv6)
    RFC2462 DS IPv6 Stateless Address Autoconfiguration
    RFC2463 DS Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
    RFC2464 PS Transmission of IPv6 Packets over Ethernet Networks
    RFC2460 DS Internet Protocol, Version 6 (IPv6) Specification
    RFC2452 PS IP Version 6 Management Information Base for the Transmission Control Protocol
    RFC2454 PS IP Version 6 Management Information Base for the User Datagram Protocol
    RFC2465 PS Management Information Base for IP Version 6: Textual Conventions and General Group
    RFC2466 PS Management Information Base for IP Version 6: ICMPv6 Group
    RFC2450 I Proposed TLA and NLA Assignment Rules
    RFC2467 PS Transmission of IPv6 Packets over FDDI Networks
    RFC2470 PS Transmission of IPv6 Packets over Token Ring Networks
    RFC2471 E IPv6 Testing Address Allocation
    RFC2472 PS IP Version 6 over PPP
    RFC2473 PS Generic Packet Tunneling in IPv6 Specification
    RFC2497 PS Transmission of IPv6 Packets over ARCnet Networks
    RFC2507 PS IP Header Compression
    RFC2526 PS Reserved IPv6 Subnet Anycast Addresses
    RFC2529 PS Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
    RFC2553 I Basic Socket Interface Extensions for IPv6
    RFC2675 PS IPv6 Jumbograms
    RFC2710 PS Multicast Listener Discovery (MLD) for IPv6
    RFC2711 PS IPv6 Router Alert Option
    RFC2732 PS Format for Literal IPv6 Addresses in URL's
    RFC2874 PS DNS Extensions to Support IPv6 Address Aggregation and Renumbering
    RFC2894 PS Router Renumbering for IPv6
    RFC2928 I Initial IPv6 Sub-TLA ID Assignments
    RFC3041 PS Privacy Extensions for Stateless Address Autoconfiguration in IPv6
    RFC3019 PS IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol
    RFC3122 PS Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification
    RFC3178 I IPv6 multihoming support at site exit routers
    RFC3146 PS Transmission of IPv6 Packets over IEEE 1394 Networks
    RFC3306 PS Unicast-Prefix-based IPv6 Multicast Addresses
    RFC3314 I Recommendations for IPv6 in 3GPP Standards
    RFC3484 PS Default Address Selection for Internet Protocol version 6 (IPv6)
    RFC3493 I Basic Socket Interface Extensions for IPv6
    RFC3513 PS IP Version 6 Addressing Architecture
    RFC3531 I A Flexible Method for Managing the Assignment of Bites of an IPv6 Address Block
    RFC3316 I IPv6 for Some Second and Third Generation Cellular Hosts
    RFC3542 I Advanced Sockets Application Protocol Interface (API) for IPv6
    RFC3587 I IPv6 Global Unicast Address Format

    Current Meeting Report


    IPv6 Working Group

    Minneapolis IETF
    November 11 & 12, 2003

    Chairs:

    Bob Hinden
    Brian Haberman

    Minutes taken by Steven Blake and Dave Thaler. Edited by Bob Hinden

    Agenda

    Tuesday, November 11, 2003

    • Introduction and Agenda Bashing, Chairs (5 min)
    • Milestone Review and Document Status, Chairs (10 minutes)
    • Local Communications Goals, Tony Hain & Fred Templin (15 minutes)
      • draft-hain-templin-ipv6-localcomm-03.txt
      • Goal: discussion of open issues
    • Tunnel MIB, Dave Thaler (10 minutes)
      • draft-thaler-inet-tunnel-mib-00.txt
      • Goal: overview of proposal, adopt as WG item?
    • Proxy RA, Dave Thaler (10 minutes)
      • draft-thaler-ipv6-ndproxy-01.txt
      • Goal: status update, adopt as WG item?
    • ICMPv6 Updates, Bob Hinden (10 minutes)
      • draft-ietf-ipngwg-icmp-v3-02.txt
      • Goal: status update

    Wednesday, November 12, 2003

    • Router Selection, Dave Thaler (10 minutes)
      • draft-ietf-ipv6-router-selection-02.txt
      • Goal: issue discussion, next steps
    • Neighbor Discovery Updates, Tatuya Jinmei (15 minutes)
      • draft-soliman-ipv6-2461-bis-00.txt
      • Goal: issue discussion
    • Stateless Autoconfiguration Updates, Tatuya Jinmei (15 minutes)
      • draft-jinmei-ipv6-rfc2462bis-00.txt
      • Goal: issue discussion
    • Scoped Address Arch Document, Tatuya Jinmei (10 minutes)
      • draft-ietf-ipv6-scoping-arch-00.txt
      • Goal: discussion of last call comments
    • Site-Local Deprecation Document, Christian Huitema (20 minutes)
      • draft-ietf-ipv6-deprecate-site-local-01.txt
      • Goal: discussion of last call comments
    • Unique Local Addresses Document, Bob Hinden (15 minutes)
      • draft-ietf-ipv6-unique-local-addr-01.txt
      • Goal: discussion of last call comments
    • Address Architecture Update, Bob Hinden (15 minutes)
      • draft-ietf-ipv6-addr-arch-v4-00.txt
      • Goal: review changes and plan for moving forward
    • Identifier/Locator Separation, Kurt Lindqvist (10 minutes)

    Introduction and Agenda Bashing, Chairs

    The Brian Haberman introduced the meeting and reviewed the agenda.

    Elizabeth Rodriquez (IMSS chair) announced that the IPv6 over FiberChannel draft is in last call in IMSS working group.

    TAHI Announcement: see slides

    Testing Event

    • Jan 19-23, 2003
    • Japan
    • New test suite (IPv6 & SIP)
    • See http://www.tahi.org for more information

    Milestone Review and Document Status, Chairs

    MILESTONES (previous dates in parenthesis)

      Done            Submit Prefix Delegation requirements and submit to
                      IESG for Informational. 
      Done            Submit TCP MIB to IESG for Proposed Standard.
      Done            Submit IPv6 Node Requirements to IESG for
                      Informational. 
      Done            Submit Forwarding Table MIB to IESG for Proposed
                      Standard. 
      Done            Submit IP MIB to IESG for Proposed Standard.
      Nov 03          Submit Site-Local Deprecation document to IESG for
                      Informational   
      Nov 03          Submit Unique Local IPv6 Unicast Addresses to IESG for
                      Proposed Standard.  
      Dec 03 (Nov 03) Submit update to ICMPv6 (RFC2463) to be republished at
                      Draft Standard. 
      Dec 03 (Nov 03) Submit Router Preferences, More-Specific Routes, and
                      Load Sharing to IESG for Proposed Standard. 
      Feb 04 (Dec 03) Submit updates to Auto Configuration (RFC2462) and
                      Neighbor Discovery (RFC2461) to be republished at Draft
                      Standard.   
      Dec 03          Submit Proxy RA to IESG for Proposed Standard 
      Dec 03 (Oct 03) Submit Link Scoped IPv6 Multicast Addresses to IESG for
                      Proposed Standard. 
      Dec 03 (Oct 03) Submit IPv6 Scoped Addressing Architecture to IESG for
                      Proposed Standard. 
      Dec  03         Submit update to IPv6 over PPP (RFC2472) to IESG for
                      Draft Standard. 
      Jan 04 (Oct 03) Submit UDP MIB to IESG for Proposed Standard.
      Jan 04 (Nov 03) Submit Requirements for Local Addressing to IESG for
                      Informational 
      Jan 04 (Nov 03) Submit Update to Privacy Extensions for Stateless
                      Autoconfiguration document (RFC3041) to the IESG for
                      Draft Standard.  
      Jan 04 (Oct 03) Resubmit Node Information Queries to IESG for Proposed
                      Standard. 
      Jan 04 (Nov 03) Re-charter or close working group.
    
    PUBLISHED & APPROVALS
      RFC's Published
        RFC3587, "IPv6 Global Unicast Address Format"
    
      IESG Approved
        none
    
    STATUS OF CURRENT WORK ITEMS
    Flow Label
     - Editor: Jarno Rajahalme
     - Milestone: Done
        o Submit for PS
     - Status: 
        o In IESG
        o New draft submitted to resolve IESG comments
     - Open Issues:
        o None known
    
    Proxy RA
     - Editor:  Dave Thaler 
     - Milestones:  Dec 03
        o Submit to IESG for PS
     - Status: New draft
        o To be discussed in WG
    
    Prefix Delegation Requirements
     - Editor:  Shin Miyakawa
     - Milestone:  Done
        o Submit for Info
     - Status: In IESG
        o New draft submitted that responds to IESG comments
     - Open Issues:
        o None known
    
    TCP MIB 
     - Editor: Rajiv Raghunarayan
     - Milestone: Done
        o Submit for PS
     - Status: Submitted to IESG
     - Open Issues:
        o None known
    
    IPv6 Node Requirements
     - Editor: John Loughney
     - Milestone: Done
        o Submit for Info
     - Status: In IESG
        o New Draft submitted that responds to AD comments
     - Open Issues:
        o None known
    
    Forwarding Table MIB
     - Editor: Brian Haberman
     - Milestone: Done
        o Submit for PS
     - Status: In IESG
     - Open Issues:
        o None known
    
    Node Information Queries
     - Editor: Matt Crawford
     - Milestone: Oct 03
        o Re-submit for PS
        o Update milestone to Jan 04
     - Status: New draft in w.g. last call
        o New draft need to resolve issues raised on mailing list and at
          Vienna IETF 
     - Open Issues:
    
    UDP MIB
     - Editor: John Flick
     - Milestone: Oct 03
        o Submit for PS
        o Update milestone to Jan 04
     - Status: New draft available
     - Open Issues:
        o none known
        o Ready for w.g. last call?
    
    IP MIB
     - Editor:  Shawn Routhier
     - Milestone: Done
        o Submit for PS
     - Status: In IESG
     - Open Issues: 
        o Will be delayed by INET Address TC
        o Dependent on Router Selection Draft
    
    Default Router Preferences
     - Editor: Dave Thaler
     - Milestone: Nov 03
        o Submit to IESG for PS
        o Update milestone to Dec 03
     - Status: AD Comments Received
     - Open Issues:
        o Split load balancing into separate document and resolve issues 
        o To be discussed in w.g.
    
    Link-Scoped Multicast
     - Editor: Jung-Soo Park
     - Milestone: Oct 03
        o Submit for PS
        o Update milestone to Dec 03
     - Status: WG Last Call
     - Open Issues:
        o No technical issues, but is it needed?
        o OK to advance?
    
    Comment: We don't need link-scoped multicast; changes SSM semantics.

    ACTION: Chairs need to post query to mailing list to determine working group consensus on how to move forward with the Link-Scoped Multicast draft.

    Scoped Addressing Architecture
     - Editor: Jinmei Tatuya
     - Milestone: Oct 03
        o Submit for PS
        o Update milestone to Dec 03
     - Status: Working Group Last Call
     - Open Issues:
        o Need to be consistent with INET Address TC on default zone values
        o OK to advance (after new draft)?
    
    Savola: Scoped Architecture cannot go forward until ICMPv6 is updated.
    Site-Local Deprecation
     - Editors: Christian Huitema, Brian Carpenter
     - Milestone: Nov 03
        o Submit for Informational
     - Status: In working group last call
     - Open Issues:
        o Issues raised on mailing list
        o To be discussed in w.g. meeting
    
    Unique Local Addresses
     - Editor: Bob Hinden
     - Milestone: Nov 03
        o Submit for PS
     - Status: In working group last call
     - Open Issues:
        o Issues raised on mailing list
        o To be discussed in w.g. meeting
    
    Requirements for Local Addressing
     - Editor: T. Hain, F. Templin
     - Milestone: Nov 03
        o Submit for Informational
        o Update milestone to Jan 04
     - Status: Individual submission
     - Open Issues:
        o Discussion on mailing list
        o Will be discussed in w.g. meeting
    
    IPv6 Addressing Architecture
     - Editor: Bob Hinden
     - Milestone: (none)
        o Re-Submit for Draft Standard
        o New milestone Jan 04
     - Status: Draft available
     - Open Issues:
        o Dependent on Site-Local deprecation
        o Will be discussed in w.g. meeting
    
    Work Not Started
     - ICMPv6 Update
     - Privacy Extensions Update
     - PPPv6 Update
    
    Textual Representation of IPv4 and IPv6 Addresses
     - Author: Andrew Main
        o 
     - Fixes a long history of broken ABNF definitions of textual
       representations 
        o Does not cover scoped address syntax or prefix length syntax 
     - Important to get this right, to ensure correct parsing by UIs, etc.
     - Request:
        o Please read it & prepare for decision whether to adopt as WG item 
        o Standards track vs Informational?
    
    Textual representation: ABNF already moved out of the Address Architecture specification some time ago.

    Jinmei: Textual representation has a relationship to address architecture. Hinden: No; this is dependent on address architecture, not the other way around.

    Carpenter: Talked to co-author (Zephram); ABNF definitions have been broken for awhile (including IPv4 dotted quad).

    ACTION: Chairs to send out note if anyone implements an ABNF parser.


    Local Communications Goals, Tony Hain & Fred Templin

  • draft-hain-templin-ipv6-localcomm-03.txt
  • Goal: discussion of open issues

    Hain : People want to tell other people how to run their networks. Not IETF business. Keith Moore: IP tells people how to run their networks. People who misuse IP can cause harm.

    Fred Templin gave remainder of presentation.


    Tunnel MIB, Dave Thaler

  • draft-thaler-inet-tunnel-mib-00.txt
  • Goal: overview of proposal, adopt as WG item?

    Savola: have you thought about what kind of IANA registry you want to have? Dave: rules should be identical to what you need to do to get an iftype value (treat iftype the same as tunneltype).

    Haberman: Should ipv6 adopt this document? Chairs call the question. No objection to making this a working group item.

    ACTION: Next version of will be an IPv6 working group document.


    Proxy RA, Dave Thaler

  • draft-thaler-ipv6-ndproxy-01.txt
  • Goal: status update, adopt as WG item? Dave Thaler gave presentation.

    Itojun: You propose to add MTU option, what is the relationship with this modification and IPsec or SEND? Dave: If there are any security parts of the RA, they are stripped (unsecured RA), or we ignore it. It looks like a router that doesn't implement SEND to hosts.

    Dave tends to agree with Brian Carpenter that this should become Informational, not PS. Any opinions?

    Droms: Any interoperability issues? Or does this merely define how a device would implement this function. Dave: mainly the router. Trying to show that you can do this without NAT.

    Huitema: what about spanning tree? Dave: Optional; don't always need loop prevention.

    Dudley: Important to default (Spanning Tree) to on. For those links that have the requirements, should it be used as default. Dave: Yes.

    Haberman: Any objection to adopting this document as a w.g. document for the ND proxy work item, as informational. No objections.

    Adopt as a working group document? For Informational. No objections.

    ACTION: Next version of will be an IPv6 working group document.


    ICMPv6 Updates, Bob Hinden

  • draft-ietf-ipngwg-icmp-v3-02.txt
  • Goal: status update

    Savola: Should we redo the w.g. last-call? Hinden: Yes, when new draft is out. Also, do we have to redo the implementation reports? Hinden: Need to look at that and check with the ADs.

    Chown: Extra ICMPv6 type: Site Exit Routers suggested in multi6. Should we add that in this document? Hinden: Not sure we should do it now; it can use experimental types.

    Haberman: Same issue with MLDv2 spec. Could have requested a code from IANA without any IETF action. Multi6 could go request a type on their own (at least until we change the IANA policy in this document).

    Question: Who is the editor. Hinden: Currently I am, and we are working for new editor. If interested, please contact the chairs.


    Wednesday, November 12, 2003


    Router Selection, Dave Thaler

  • draft-ietf-ipv6-router-selection-02.txt
  • Goal: issue discussion, next steps

    Savola: Don't use uppercase "may" in last guideline on slide 5. Thinks it is a misuse of terminology. Narten: Recommendations for operators or implementors. A: Operators. First three will be lower case, last will be upper case.


    Neighbor Discovery Updates, Tatuya Jinmei

  • draft-soliman-ipv6-2461-bis-00.txt
  • Goal: issue discussion

    security/mobility issues raised
    bug fixes, increase clarity
    goal is another Draft Standard RFC
    restrictions on new functionality Updates to RFC 2461 (Hesham primary editor)

    1) mixed host/router behavior (on diff interfaces)
    Proposal: state distinction is per interface

    Templin: can you have a router with 1 interface? A: Yes

    2) what if pref life > valid life?
    Proposal: MUST NOT send

    3) onlink assumption considered harmful
    Proposal: remove this assumption

    4) router lifetime values "inconsistencies". Does >18.2 hours violate spec?
    Proposal: allow any value up to 65535, don't change sending behavior in section 6

    5) clarify M/O flags in context of DHCPv6
    Proposal: say stateful for M is RFC 3315 need similar reference for O

    Greg Daley: dependency issues, O reference is just a draft

    6) what happens if host receives prefix length > 64
    Proposal: ignore and assume a 64-bit prefix? to be discussed on list

    15) do we have to mandate link-local addresses as source in redirects? Proposal: yes, no change

    7-9 are security issues Proposal: add a section on securing ND and refer to SEND for dynamic security

    expand security considerations section based on send-psreq draft
    add discussion on manual vs dynamic keying, currently vague

    13) omission of prefix options considered harmful
    Proposal: handle with ND extensions for movement detection not in this spec

    14) introduce globally unique link id for movement detection
    Proposal: handle with ND extensions not in this spec

    10) relax requirements on RA frequency to allow 50ms
    Proposal: allow, but not sure if safe

    11) remove random delay in MNs before RS
    Proposal: change 6.3.7 to allow no delay if know a hand-over (not startup, etc) has taken place

    12) remove random delay in routers before RA
    Proposal: draft-mkhalil-ipv6-fastra-*

    Kempf: issues raised, may not want in this spec

    Narten: legitimate for mobility but need to look at as part of the whole problem useful to talk about in DNA, wary of changing this spec.

    Bound: Agree w/ Narten. Just pull these from the recycle issues and move forward.

    Narten: put them on hold, don't adopt them at this point may adopt them later if get resolution when document is still open

    Nordmark: #11 need to explain motivation for delay... power failure case clarifying intent may help the other discussion.

    Kempf: talk to security AD on 7-9

    Daley: interested in looking at issues in DNA but not committing

    Huitema: don't add anything, have implementation experience with current draft and want to keep moving forward

    Narten: don't make specific changes now

    Itojun: limit to clarifications, don't introduce new stuff

    15) remove delay before NS
    Proposal: discuss

    18) add R/H flags per MIPv6 spec
    Proposal: accept

    Mobility: Clarifications now, but not new features.
    Limit effort to clarification..


    Stateless Autoconfiguration Updates, Tatuya Jinmei

  • draft-jinmei-ipv6-rfc2462bis-00.txt
  • Goal: issue discussion

    Some issues already have consensus on list others:

    6) src addr selection issues: prefer link-local vs deprecated
    Proposal: add reference to RFC 3484

    7) deprecated addr handling, semantics of "new" communication consensus: incoming TCP connection is not "new"
    Proposal: use text proposed on list
    also talk about case where application specified deprecated address

    8) semantics of L=0 A=1 case (addr configurable but not on link)
    Proposal: no change

    9) stable storage for auto-configured addr for stability
    Proposal: mention it but not mandate

    10) issues raised in send "use IPsec" is not enough
    Proposal: add summary to security considerations, no change in protocol

    11) DAD for 802.11
    2462 says don't drop just because Llayer source != receiving node
    802.11 doesn't meet this
    Proposal: add note in Appendix A and reference draft-park-ipv6-dad-problem-wlan

    Suggestion was made to have an IPv6-over-WiFi specification.

    12) conflict with MLD spec re random delay for first packet
    2462: if NS for DAD is 1st pkt, random delay
    MLD report is usually the first packet
    Proposal: just add a note? not a problem in _this_ spec

    Dino: so don't send MLD reports for link-local addresses Daley: that would break things

    13) DAD relayed issues: dad delay, random delay, how optimize dad
    spec: SHOULD do DAD for every unicast addr
    MAY skip DAD in some cases
    should we remove the MAY?
    Proposal: DAD optimization is a separate draft
    need discussion on list

    15) semantics of M/O
    what requirement keyword, and specify DHCPv6?
    Proposal: should mention DHCPv6, need to discuss details

    16) whether a non-host router can use autoconf
    a) configure a global addr
    b) configure a link-local addr
    c) configure itself about "other" information
    Proposal: a=NO, b=YES, c=NO

    Haberman: clarification - you mean per-interface definition right? Jinmei: yes

    17) 'not-yet-ready' status of an autoconf addr for renumbering
    can deprecated addr be used?
    Proposal: out of scope of this update, specify as extension

    18) avoiding intf failure on DAD failure
    2462: SHOULD be disabled if no link-loc addr
    Proposal: SHOULD but MAY allow automatic recovery

    19) 2462 requires a 64-bit ID
    same issue as 2461
    no suggestion so far
    Proposal: discuss on list

    Itojun: is there an issues list page?
    ?: #13 what do you mean by "strict"
    Jinmei: force DAD not DID
    #18 MIPv6 suggested 3041 id in this case, should 2462 suggest A mechanism?
    Hinden: need to be careful making changes
    Huitema: #18 is really a security violation, bad guy can disable everyone's interfaces.

    Chairs called question of making ND and Addr-Conf w.g. documents. No objections . Next version of drafts will be w.g. documents.

    ACTION: Next versions of and will be IPv6 working group documents.


    Scoped Address Arch Document, Tatuya Jinmei

  • draft-ietf-ipv6-scoping-arch-00.txt
  • Goal: discussion of last call comments last call issued Oct.22
    most issues have consensus on list

    Default zone ID value
    draft suggests but does not require 0
    issue: MIB needs 0
    Proposal: SHOULD use zero

    Thaler: why SHOULD and not MUST? (for MIB compliance)
    Haberman: just make sure MIB and this doc agree
    Itojun: can we get implementation reports and if no one uses non-zero then can use MUST

    Alignment with draft-main-ipaddr-text-rep
    Proposal: add a reference to the text-rep draft
    normative or informative?

    Haberman: make sure reference looks like the ref in the addr arch doc
    (informative)

    number of authors > 5

    default zone ids for "subnet-local" multicast scope
    Proposal: remove subnet-local, already removed from 3513 and addr-arch-v4

    references ICMPv6 update as a normative reference
    shouldn't be a problem (do concurrently)


    Site-Local Deprecation Document, Christian Huitema

  • draft-ietf-ipv6-deprecate-site-local-01.txt
  • Goal: discussion of last call comments

    Huitema was called up to discuss, no slides

    two main comments
    1 (Pekka etc) more text about why NAT is bad, e.g. from Margaret SL-IMPACT Proposal: OK
    2 recommendation for deprecation
    current: existing behavior MUST be ignored by any new implementation
    Q: what is a new implementation, is there a flag date, what if shipping both old and new versions, etc
    one way: write weasel text
    other way: replace MUST by SHOULD (Huitema prefers this)
    rationale: writing more text doesn't help

    Hinden: Thinks current text is just fine.

    Carpenter: tends to agree with hinden, IETF doesn't have a clear procedure for versioning. No objection to SHOULD but like it with no changes. Leave it up to the implementor how to handle

    Nordmark: may be helpful to add a sentence to state the intent?
    Huitema: we already say that

    Hinden consensus summary: Leave deprecation text as is and bring in two paragraphs from Margaret's document.

    Haberman took consensus call: Any objection? No

    ACTION: Chairs will advance when next version of draft is out.


    Unique Local Addresses Document, Bob Hinden

  • draft-ietf-ipv6-unique-local-addr-01.txt
  • Goal: discussion of last call comments

    Last call started Oct.22
    Hinden is active author, Haberman is shepherding chair

    Need for ULAs need to provide for local disconnected/intermittent allocation
    Proposal: yes, better than other known alternatives

    Huitema posted summary to the list of alternatives and problems with them

    Application handling?
    do applications need special knowledge about these addresses?
    not introduced by this type of address, also applies to firewalls etc
    useful to investigate general solutions to this class of problems
    impact to source/destination addr selection?
    will longest match rules just work?
    provide more feedback via ICMP errors

    Moore: agree don't burden address scheme with this
    need to change address selection to get other things to work
    it's hard enough to get address selection right, will probably have to change it anyway

    Nordmark: ULAs are different than filtering etc, they're not reachable by design

    Moore: by design they're not globally reachable, but it's a stretch to say they're not reachable by the peers of interest. Don't want applications to assume they're not reachable if not global

    Nordmark: wrong impression is dangerous

    Moore: hard enough to get right

    Itojun: agree with Nordmark

    Daley: this is a routing problem, why not just send destination unreachable Hinden: see later slide, discussed later in the talk.

    Leakage Doc provides reasonable measures to prevent most leakage
    Uniqueness minimizes impact
    Leakage also affects firewalled addresses, etc
    ULA is a good tradeoff among alternatives

    Itojun: different types of filtering (e.g. don't advertise routes, do advertise and filter data, etc)

    Charging, IANA instructions
    IETF documents can't specify a specific charge or use of revenue
    Proposal: remove 10 Euro and say low cost and intent to prevent hoarding
    Geoff Huston (who raised issue) is okay with the new proposed text.

    Filtering
    black holing has bad side effects
    Proposal: MAY respond with ICMP admin prohibit

    Savola: is MAY strong enough?
    Hinden: isn't ICMP always a MAY? should be consistent with other places
    Savola: then change to SHOULD
    Hinden: OK
    Itojun: if we don't advertise then who will send admin prohibited
    Thaler: diff subtypes for different filtering methods
    Iljitsch van Beijnum: New ICMP message for source not right?
    Haberman: scope exceeded does that
    Iljitsch: is "scope" global here?
    Moore: three cases
    1) trying to send out to global internet
    2) trying to send to a ULA with no route
    3) filtering between two local networks
    Carpenter: ICMP is likely to cross admin boundaries which may block ICMP not bad to define but can't rely on them arriving
    Moore: can be defined and work most of the time

    Alternative random algorithm Proposal: make sure others are allowed

    Best name Proposal: take to list
    Haberman: prefer really cool acronyms :)

    Propose to make the changes discussed and advance?

    Chown: language says need globally unique, but is probabilistically unique should be more clear

    Haberman calls for consensus:

    Any objection to proposed changes? No?
    Submit to IESG with changes? Yes?

    Moore: clarification - will revised document redo WG last call?
    Haberman: we could have 1 week last call

    Itojun: please ask whether we need another last call
    Wasserman: yes

    Iljitsch: locator/identifier separation work coming, not sure we should standardize something different
    Hinden: Not advisable to wait
    Narten: Right
    Carpenter: sentence used to be there "might be useful for Multihoming too" make sure it's out. Hinden thinks it's already out.
    Iljitsch: are they unroutable by design or by lack of a way to do it? so clarify.
    Hinden: says "not routable with currently technology" or something
    Kurt Lindqvist: don't wait
    Wasserman: there's no conflict with locator/identifier work

    ACTION: Chairs will start short working last call for when new draft is available.


    Address Architecture Update, Bob Hinden

  • draft-ietf-ipv6-addr-arch-v4-00.txt
  • Goal: review changes and plan for moving forward

    site-locals removed from special list of prefixes
    added text describing SL deprecation
    added instructions in IANA considerations to reserve and not reassign
    changes dependent on approval of SL Deprecation document

    changes due to IAB recommendations
    2.5 nodes shouldn't make assumptions about address structure
    2.5.1 nodes aren't required to validate that u=1 is unique


    Identifier/Locator Separation, Kurt Lindqvist

    Multi6 WG update

    A number of proposal (6 active drafts, more expired) many/most split identifier (who) and locator (where) semantics and syntax vary for most, locators are todays IPv6 addresses

    impact:

    • We will not turn off ipv6 :-)
    • All proposal will try to have no impact on ULPs
    • Most involve a shim layer between ULPs and IP
    considerations:
    • secure mapping of id<->locator
    • goals are in RFC 3582
    • more operational considerations being written (current drafts from Nordmark, crocker)
    Itojun: SONY LIN6 draft mentions patent pending, so may be IPR issues


    Meeting Adjourned


  • Slides

    Agenda
    Goals for Local Communications Within Sites
    Inet Tunnel MIB
    NDProxy Status Update
    ICMPv6 Update
    Router Selection Status
    Neighbor Discovery Updates - Intro
    Neighbor Discovery Updates
    Stateless Autoconfiguration Updates
    Scoped Address Arch Document
    Unique Local Addresses
    IPv6 Addressing Architecture Update