Subject: Revised IPng Working Group Charter

From: Bob Hinden <[email-masked]>
Date: Fri, 23 Jun 2000 14:34:31 -0700

Folks,

Attached is a draft of a revised charter for the working group.  Updating 
the charter was agreed to at the Grenoble and Minneapolis working group 
meetings, but it took the chairs and AD's a while to draft a new one.

The charter includes changing the name of the working group to the "IP 
Version 6 Working Group", but will keep the acronym of "ipngwg".  This will 
avoid having to rename all current internet drafts.

Please send comments on the new charter to the mailing list.  There will be 
a short session in Pittsburgh to discuss it as well.

Bob Hinden / Steve Deering

-----------------------------------------------------------------------------
Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft
-----------------------------------------------------------------------------

IP Version 6 Working Group (ipngwg)  *** note: change of name but not acronym

Chair(s):

    Bob Hinden <[email-masked]>
    Steve Deering <[email-masked]>

Document Editor

    Bob Hinden ([email-masked])

Internet Area Director(s):

    Thomas Narten <[email-masked]>
    Erik Nordmark <[email-masked]>

Internet Area Advisor:

    Thomas Narten <[email-masked]>

Mailing Lists:

    General Discussion:[email-masked]
    To Subscribe: [email-masked]
    In Body: in body: subscribe ipng
    Archive: ftp://playground.sun.com/pub/ipng/mail-archive

Description of Working Group:

    IP version 6 or IPv6 (also formerly known as IP Next Generation or IPng)
    is intended to support the continued growth of the Internet, both in
    size and capabilities, by offering a greatly increased IP address space
    and other enhancements over IPv4.  The working group was originally
    chartered 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.  Most of
    the tasks in that original charter have been completed, and the core
    IPv6 protocol specifications are now on the IETF standards track.
    The working group's ongoing responsibilities are as follows:

     - Complete work from the original charter and follow-on work, as
       outlined below.

     - Keep all IPv6 working group documents moving along publication /
       standardization track.

     - Serve as a review board and body of competence and coordination for
       IPv6 architectural issues that span multiple IETF working groups.

     - Provide a home for IPv6-related work that doesn't fit in an existing
       IETF working group and doesn't merit a working group of its own.

     - Provide technical input to ICANN, Internet Address Registries, and
       IANA with regard to IPv6 address allocation policies and procedures.

     - Provide technical input and review to IANA with regard to IPv6
       protocol and parameter assignments.

    The list of the working group's current work items is as follows:

     - Revise ICMPv6 spec (scope-exceeded err, no error to redirect,
       editorial)
     - Revise Generic Tunneling spec (add bidirectional tunnels)
     - Update Basic and Advanced API specs
     - Complete Router Renumbering spec
     - Complete Scoped Address Architecture spec and any necessary revisions
       to other working group drafts required to properly implement support
       for IPv6 address scoping
     - Complete work on recommended address-selection algorithms
     - Work on new solutions to site-multihoming problems, possibly including
       both host-based and router-based solutions.
     - Complete work on local IPv6 networking as part of IPv6 plug-and-play
     - Complete work on privacy extensions to stateless address configuration
     - Document IPv6 renumbering model
     - Complete the GSE Analysis document
     - Complete the Inverse Neighbor Discovery spec
     - Complete the IPv6 Node Information Queries spec
     - Complete MIB specs as required by any working group protocol specs

    New work items not listed above require the approval of the working
    group and Internet Area directors before they will be taken on by the
    working group.

    The working group would welcome contributions on the following topics
    (this is not an exhaustive list):

     - Flow label standardization
     - Solutions to other multihoming issues, beyond those specific to
       site-multihoming
     - Integration of autoconfiguration, mobility, DNS, service discovery
       and other technologies to enhance IPv6 plug-and-play
     - IPv6 dial-up issues relating to address assignment, use of Neighbor
       Discovery, etc. (not including AAA work)
     - Specifications for IPv6 over additional media
     - Extending MLD to include functionality of IGMPv3
     - Host use of anycast; TCP use of anycast
     - Support for multi-link subnets (single subnet spans multiple links)
     - Scope-name discovery
     - IPv6 protocol extensions to accommodate mobile wireless networks.

Goals and Milestones:

  Aug 2000    Complete MLD MIB and submit for Proposed Standard

  Aug 2000    Complete privacy extensions specification and submit for
              Proposed Standard

  Aug 2000    Completed revision of GSE Analysis document and resubmit
              for Informational

  Aug 2000    Complete the Inverse Neighbor Discovery specification
              and submit for Proposed Standard

  Aug 2000    Complete IPv6 Multihoming with Route Aggregation and submit
              for Informational.

  Oct 2000    Update ICMP document and resubmit for Draft Standard

  Oct 2000    Update Generic Tunneling specification and resubmit for
              Proposed Standard

  Oct 2000    Complete updates to Basic and Advanced API specifications
              and submit for Informational

  Dec 2000    Complete Scoped Address Architecture and submit for Proposed
              Standard

  Dec 2000    Compete Address Selection specification and submit for Proposed
              Standard

  Dec 2000    Complete Local IPv6 Networking Specification and submit for
              Proposed Standard

  Dec 2000    Complete the IPv6 Node Information Queries specification
              and submit for Proposed Standard

  Mar 2001    Complete IPv6 renumbering model document and submit for
              Informational

-----------------------------------------------------------------------------
Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft
----------------------------------------------------------------------------- 

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Jim Bound <[email-masked]>
Date: Mon, 26 Jun 2000 21:48:36 -0400

Bob,

I think we need to also discuss the global identification of the
reserved bits in the site-local address.  If this can be done then IPv6
will be able to be deployed without causing alterations to Internet
network server applications like DNS, DHCP, and Network Server Database
Applications on customers networks.

regards,
/jim

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 27 Jun 2000 08:54:38 -0400

At/À 14:34 2000-06-23 -0700, Bob Hinden you wrote/vous écriviez:
>Version 6 Working Group", but will keep the acronym of "ipngwg".  This 
>will avoid having to rename all current internet drafts.

The chairs have probably talked about it, but I would suggest to change the 
acronym, since:
- we want to "get rid" of ng
- ipngwg is the one of the few wg that have "wg" in their acronym
- acronym is used often in presentations, media, etc..., so it has 
importance too.

Would suggest "ipv6" as acronym.

>    The list of the working group's current work items is as follows:

host and router requirements doc ?

>Goals and Milestones:

Given the work items, it seems to me that the milestones are pretty aggressive.

Marc.

Marc Blanchet
Viagénie inc.
tel: 418-656-9254
http://www.viagenie.qc.ca

----------------------------------------------------------
Normos (http://www.normos.org): Internet standards portal:
IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Jun 2000 11:07:16 -0500

I can't hekp wondering whether the flow label issue should be sent off
to the Transport area for consideration. 

  Brian

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 28 Jun 2000 01:23:46 +0900

I'm not sure if I have sent this already.  please forgive me if
	there's duplicate messages.

>     - Host use of anycast; TCP use of anycast

	and also UDP.  UDP anycast will be very useful for DNS.  most of
	already-defined UDP services require us to use the same src/dst pair
	for query/reply (reverse order for reply, of course).  therefore,
	we have conflict between them.

itojun

---

From: Jim Bound <[email-masked]>
Date: Tue, 27 Jun 2000 15:12:32 -0400

flowlabel should be done here or in routing area.
those are the people who understand it and ramifications.

/jim

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Jun 2000 15:11:03 -0500

But the people who understand QOS are in the transport area, and so far
they have ignored it.

  Brian

---

From: Jim Bound <[email-masked]>
Date: Tue, 27 Jun 2000 16:33:24 -0400

>But the people who understand QOS are in the transport area, and so far

I would agree that the rsvp work folks did supports that.  but I also
think there are a lot of "implementation" issues and thats not there yet
to my knowledge in the transport area.  we would have to transport folks
from here to the transport area for sure.  

Why not have them come to IPv6 WG to work on it instead?

/jim

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Jun 2000 16:23:18 -0500

Jim, it's not just RSVP, there is also diffserv where I see a lot
of very practical implementation people. Wouldn't you rather
infect the TSV area with IPv6 than have them in a network area WG?

   Brian

---

From: Jim Bound <[email-masked]>
Date: Tue, 27 Jun 2000 20:06:49 -0400

Brian,

>infect the TSV area with IPv6 than have them in a network area WG?

Excellent point on infecting TSV.  Ok I am sold.
I just hope the efforts are better than I have been able to do to get
dhcpv4 people to work on DHCPv6.  Mike, Charlie, and I just put together
what I think is a pretty good piece of work.  Except for Francis we have
had no input.  Unfortuneately in dhc WG they want to hear yeah or nay.
Unlike here.  We think we have addressed all persons issues which was a
real lot of work.  Anyway I am not moaning about it but trying to get areas 
to work on IPv6 is still an up hill battle.  I believe the IESG and IAB
are doing great now with IPv6 (and for awhile) now we need to get the
rest of the community on board.

regards,
/jim

---

From: "Matt Crawford" <[email-masked]>
Date: Thu, 29 Jun 2000 10:21:20 -0500

> those are the people who understand it and ramifications.

I disagree.  It should be in routing or transport, so they can shed
the blood over whether it's end-to-end or hop-by-hop-mutable.

			Matt

---

From: Jim Bound <[email-masked]>
Date: Thu, 29 Jun 2000 12:52:48 -0400

hi matt,

I agree. brian showed me the error of my ways too :---)

thx
/jim

---

From: Alex Conta <[email-masked]>
Date: Thu, 29 Jun 2000 14:43:06 -0400

While I agree  with the chairs and the WG that the flow ID work must be completed,
and I agree with you that the expertise in other IETF areas can be very useful to
get the flow label work going, I am concerned that the work
has less of a chance to be completed without a specific WG to do it.

The "TraffiC Class" field is an example where things worked well: the output from
the Diff-Serv WG affects directly
the field.

Did you have in mind something similar when you made the suggestion?

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Jun 2000 15:35:10 -0500

Alex, I don't think the issue is separable from other QOS issues. That
means that DIFFSERV, INTSERV and ISSLL are all concerned at some level.
So I think it needs to be raised first in the TSV Area meeting. 
I agree that once the topic has been clarified, a work item should
be identified and then we can see which WG should handle it - it can't
be left floating.

(I'm much less clear about routing, I have to say. I suspect that flow-label
based routing would prove to be a pure rathole.)

  Brian

---

From: Alex Conta <[email-masked]>
Date: Thu, 29 Jun 2000 18:03:13 -0400

Brian,

I agree with you that the flow ID work should be focused on QoS specifics (flow
identification and classification) rather than  routing.

IMHO any serious focus on flow ID routing would intersect sooner or later with MPLS, and
the folks in the MPLS WG have done a lot of the  the work on  labeling flows and
forwarding flows based on labels  in such a way in which that work stands on its own,
independent of IPv6, or the IPv6 header format. Which is to say that there is not too
much to do in IPv6 for that purpose.

Alex