Last Modified: 2003-10-24
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.
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. |
RFC | Status | Title |
---|---|---|
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 |
IPv6 Working Group
Minneapolis IETF
Chairs:
Bob Hinden
Minutes taken by Steven Blake and Dave Thaler. Edited by Bob Hinden
Tuesday, November 11, 2003
Wednesday, November 12, 2003
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
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.
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.
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.
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
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
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.
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.
security/mobility issues raised
1) mixed host/router behavior (on diff interfaces)
Templin: can you have a router with 1 interface? A: Yes
2) what if pref life > valid life?
3) onlink assumption considered harmful
4) router lifetime values "inconsistencies". Does >18.2 hours violate
spec?
5) clarify M/O flags in context of DHCPv6
Greg Daley: dependency issues, O reference is just a draft
6) what happens if host receives prefix length > 64
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
13) omission of prefix options considered harmful
14) introduce globally unique link id for movement detection
10) relax requirements on RA frequency to allow 50ms
11) remove random delay in MNs before RS
12) remove random delay in routers before RA
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
18) add R/H flags per MIPv6 spec
Mobility: Clarifications now, but not new features.
Some issues already have consensus on list
others:
6) src addr selection issues: prefer link-local vs deprecated
7) deprecated addr handling, semantics of "new" communication
consensus: incoming TCP connection is not "new"
8) semantics of L=0 A=1 case
(addr configurable but not on link)
9) stable storage for auto-configured addr for stability
10) issues raised in send "use IPsec" is not enough
11) DAD for 802.11
Suggestion was made to have an IPv6-over-WiFi specification.
12) conflict with MLD spec re random delay for first packet
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
15) semantics of M/O
16) whether a non-host router can use autoconf
Haberman: clarification - you mean per-interface definition right?
Jinmei: yes
17) 'not-yet-ready' status of an autoconf addr for renumbering
18) avoiding intf failure on DAD failure
19) 2462 requires a 64-bit ID
Itojun: is there an issues list page?
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
Default zone ID value
Thaler: why SHOULD and not MUST? (for MIB compliance)
Alignment with draft-main-ipaddr-text-rep
Haberman: make sure reference looks like the ref in the addr arch doc
number of authors > 5
default zone ids for "subnet-local" multicast scope
references ICMPv6 update as a normative reference
Huitema was called up to discuss, no slides
two main comments
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?
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
Last call started Oct.22
Need for ULAs
need to provide for local disconnected/intermittent allocation
Huitema posted summary to the list of alternatives and problems with them
Application handling?
Moore: agree don't burden address scheme with this
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
Itojun: different types of filtering (e.g. don't advertise routes,
do advertise and filter data, etc)
Charging, IANA instructions
Filtering
Savola: is MAY strong enough?
Alternative random algorithm
Proposal: make sure others are allowed
Best name
Proposal: take to list
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?
Moore: clarification - will revised document redo WG last call?
Itojun: please ask whether we need another last call
Iljitsch: locator/identifier separation work coming, not sure we should
standardize something different
ACTION: Chairs will start short working last call for
site-locals removed from special list of prefixes
changes due to IAB recommendations
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:
|