2.3.11 IP Version 6 Working Group (ipv6)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. 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-01-18

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@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
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 starting to see 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, and to review and update the IPv6 specifications
based on implementation and deployment experience, and advancing them
on
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
  publish.
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
  Standard.
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
Dec 04  Submit document defining DAD optimizations to the IESG for Proposed Standard
Dec 04  Submit Load Sharing to IESG for Proposed Standard
Dec 04  Submit updates to Neighbor Discovery (RFC2461) to be republished at Draft Standard
Jan 05  Submit Centrally Assigned Unique Local IPv6 Unicast Addresses to IESG for Proposed Standard
Jan 05  Submit Proxy ND to IESG for Informational
Jan 05  Resubmit Node Information Queries to IESG for Experimental status
Jan 05  Submit update to IPv6 over PPP (RFC2472) to IESG for Draft Standard
Jan 05  Submit Update to Privacy Extensions for Stateless Autoconfiguration document (RFC3041) to the IESG for Draft Standard
Mar 05  Submit update to IPv6 Address Architecture to the IESG for Draft Standard
Apr 05  Re-charter or close working group.

Internet-Drafts:

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

    Request For Comments:

    RFCStatusTitle
    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

    Current Meeting Report


    IETF 62 ipv6 wg meeting minutes
    ===============================

    People referenced in minutes
    ============================
    Brian Haberman (Brian)
    Margaret Wasserman (Margaret)
    Jinmei Tatuya (Jinmei)
    Pekka Savola (Pekka)
    Alain Durand (Alain)
    Bob Hinden (Bob)
    Rob Austein (Rob)
    Hideaki Yoshifuji (Hideaki)
    Mukesh Gupta (Mukesh)
    Dave Thaler (Dave)
    Elwyn Davies (Elwyn)
    Thomas Narten (Thomas)
    George Michelson (George)
    Bill Fenner (Bill)
    Stig Venaas (Stig)
    Mark Andrews (Mark)
    Olafur Gudmundsson (Olafur)


    Agenda and Document Status
    ==========================
    Brian Presenting
    No one had any comments on the Agenda during Agenda Bashing

    Jinmei has a comment on the Doc status. He wants to know next steps for 2462bis as ADs need implementation status reports .

    Margaret needs info if former impl reports apply (just checking to make sure). Also need statement from chairs and pointer to the old impl report to this effect. Mukesh Gupta (Mukesh) wants to know if the implementation reports are needed for the ICMPv6 revised draft as well. Brian clarifies they are needed for both ICMPv6 and for 2461bis. He also clarifies that they are not needed if the existing implementations are not affected. The loosening of algo for privacy addrs, for example, has no effect on existing implementations. Pekka thinks the reports are so general, that is hard to infer anything specific from them.Margaret thinks that they may not be complete but they were good enough for the first time. IESG will not force to redo a new format for the Implementation Reports

    ULA update
    ==========
    Margaret presenting

    She has no slides. She already sent the info to the ML.

    IESG review found an issue with the DNS section. The issue was the increased load due to reverse lookups on DNS. Added text to resolve this.The text Reverse queries MUST NOT be sent out of the site.

    Alain is worried about how this will be implemented on the routers or on DNS servers? Mark thinks that basic premise is that this traffic should not leave the site and must egress filter it and must tell the client it does not exist. He said para had MUST in upper case.Brian and Margaret think that this is operational guidance and cannot use normative language.

    Alain and Pekka think that if it needs to be in a DNS implementation it needs to be normative. Alain wants a separate document addressing the dns related issues and does not want this text here. After discussion between Alain, Margaret, and Bob agree to have the issue mentioned both in the ULA document and another separate document. Rob clarifies that this text does not apply to centrally assigned ULAs, which most likely will have a real reverse tree.

    Alain thinks we need a BCP document containing the list of prefixes. Brian agrees with Alain. We have a problem which is holding up this doc. That is what we are fixing. We cannot wait for another doc to go all the way during the process.Margaret thinks there are 3 options 1) get the text in this doc and publish it2) wait for the other document and add a norm reference to it 3) do nothing. Alain: thinks there is a 4th option 4) take great care in this and point to an informative reference. He refers to RFC1918 that had text which said don't put this on the net. that does not work. We will have legacy clients still generating queries. We need to fix this in the servers

    Pekka is worried about the effects this will have on caching resolvers that every host needs to be modified. Olafur feels that this will cause least damage as opposed to not doing this. Margaret: It does not hurt you any more if you get a no from your ISP rather than from the root server. Rob thinks we need to pick a default (pass or don't pass). This is the lesser of 2 evils. Make it a config option. we should not harm the public net. Pekka is concerned whether the people who use ULA will see it the same way.

    Pekka: It is just not clear, that the people who use ULA will see this.

    Jinmei and Alain don't want this work to be done in the IPv6 wg. Rob and Mark also think this should be done in the DNS space in the long term and this is a short term fix.

    Brian wants to use this text as a rough guideline and asks for a show of hands.

    (CONSENSUS CALL)
    Who wants to see this text in the doc? about 15 hands
    Who does not? one or two hands
    (CONSENSUS IN FAVOR)

    Alain thinks the second question was a bit loaded.

    Brian rephrases Q2 to be "Who does not feel this text should in this document and be in another document"? 3 hands

    Update to address arch
    ======================
    Bob presenting
    It was approved as DS. There was an appeal. To resolve the appeal it was published as PS. There is most likely an implementation report already. The main changes were to resolve issues raised in Robert Elz's appeal and to deprecate site local. There were also a few mainly editorial changes. Bob will remove confusing text in the multicast scoping part of the draft.Pekka wants compatible addresses removed from the spec. Tim agrees. Bob thinks there are people who still want them in. Pekka feels that there was no consensus on ML. We should get the consensus here. Bob thinks that we should probably leave it alone as we are recycling an exisiting standard.

    (CONSENSUS CALL)
    Brian
    Q1) Who wants to remove of ipv6 mapped addresses.
    (no hands)
    (CONSENSUS AGAINST REMOVAL)
    Q2) compatible addreses
    who wants them to be removed? 20 hands
    who does not want it removed? 3 hands
    (CONSENSUS IN FAVOR OF REMOVAL)

    Hideaki does not want compatible addrs removed. He wants the address space not to be reused. He is ok with deprecation.

    (CONSENSUS CALL)
    Bob: Do we want to deprecate them? about 10 hands
    No? 1 hand
    (CONSENSUS IN FAVOR OF DEPRECATION)

    2461bis
    Brian to be Hesham
    ==================
    The last major issue left is the processing messages without the SLLAO option. Will be adding text from Greg Daley to clarify this case. Will make sure that Hesham will send the propsed changes to ths list. Jinmei and Greg agree to take it on the list

    (Reordering of presentations)

    icmpv6
    ======
    Mukesh presenting

    Major changes are
    * text to allow disabling of sending Destination unreachable messages will be added as a SHOULD
    * will remove security replated processing details for icmpv6 packets and add an informative reference to 2401bis. There is a downref issue if this needs to be done.
    * New text for source address determination from Elym to be included as 2.2 (b) instead of 2.2 (b),(c) and (d)

    Discussion between Suresh, Bob, Dave, Elwyn and Pekka on whether the sender should try to make the error message more informative when the the receiver might not know this or may not want to know this. Pekka thinks that adding this as a SHOULD will cover the existing implementations

    Pekka the previous SHOULD will cover the existing implementations

    ndproxy
    ===========
    Dave presenting

    Dave talks about why we need ndproxy and what are the characteristics of ndproxy. The doc is aimed to be EXPERIMENTAL. Loop prevention was a major issue in the ML discussions. Added text to say loop prevention is a MUST (and allow two ways to do it STP / physical constraints)

    Erik had a new suggestion (P bit in RA)
    -> if clear and on upstream proxy would set and forward on downstream
    -> if set or on downstream the proxy would disable proxy func on that interface for some time.
    hold down time of 2*maximum RA interval = 60 mins

    now the draft has 3 options (P/STP/physical constraints)

    Bob suggested the option (c) - physical constraints should be removed and the authors agreed. Pekka agrees with removing (c). Suresh is concerned that if a network contains some ndproxies which use the P-Bit and some which use STP there will be an issue. Greg suggests adding an appendix clarifying this.

    SEND interoperability is another issue which remains. Dave talks about a draft draft-daley-send-spnd-prob-01 which talks about the scenarios send is not a blocking issue as long as the draft is consistent. The explicit requirement for send interop has been removed.

    Alain wants to know if this is related to trill? Brian thinks it is not and is independent.

    IAB ipv6 ad-hoc committee report
    =========================
    Thomas presenting

    RIRs were starting to request large allocations from IANA(>/23). IANA wanted advice from the IAB. The ad hoc committee was formed to advice IAB on ipv6 addressing matters

    Related drafts
    Format of the IANA registry huston-ip6-iana-registry-05
    ip6.int deprecation huston-ip6-int-01

    Alain wants to know if there are stats for number of queries for ip6.int as he is concerned about the impact of doing this to existing equipment. Thomas does not have them. George has info collected over 2 years. He will make the info public, but he said the volume is pretty low but not trivial. George thinks that there will be some impact but we must not overstate this.

    Thomas thinks allocating /23s to RIRs is not a good idea for agrgegation. The RIRs think /12 or /16s are better. He also thinks that we need to have a good balance between aggregation and conservation (in ipv6 the balance is more towards aggregation). The IETF interested in long term stewardship, and not day to day management. We need to get good aggregation over time

    Currently each RIR has its own policy but they should converge on same process before going forward. We need to document technical considerations of allocation sizes, reservations etc. huston-ipv6-hd-metric-00 needs community review

    Pekka thinks is not appropriate to discuss it here. Thomas and Pekka kind of agree on v6ops.

    Bob announces that Thomas is retiring as AD. Thomas has been active a lot in the ipv6wg. Bob wants to give him a big hand.

    (The crowd goes into WILD APPLAUSE)

    Thomas has had a lot fun and is continuing to have fun


    ipv6 scope identifiers in URIs
    ==============================
    Bill presenting

    There is an issue with representing IPv6 scope IDs using URIs as % is used to introduce % encoded chars. There are three ways to go about fixing this

    1) Use a non-% character which fits existing grammar: We cannot copy and paste
    2) Use %25 :It needs update to uri spec and we still cannot copy and paste
    3) Continue to use % : Does not fit URI spec. Exception to fundamental URI rule

    Dave thinks Scope IDs appearing on the wire is a bad thing. Bill agrees with him. Margaret thinks these are being used in some docs the IESG has passed. Dave thinks this is OK to do as long as they are not called URIs. Margaret agrees with Dave. Brian, Bob, Mukesh think there is some utility for this. Jinmei is not convinced. Stig thinks there is no need to cut and paste as these URIs will only be used internally by applications. Brian wants to continue discussion on the ML as time is up.

    (END OF MEETING)

    Slides

    Agenda
    IPv6 Addressing Architecture Update
    Draft-ietf-ipv6-2461bis-02 update
    NDProxy Issues
    ICMPv6 Update
    IABIPv6 AdHoc Committee
    A Format for IPv6 Scope Zone Identifiers in Literal URIs