IP"NG" and IPv6 are not the same thing....NG refers to Next Generation (i.e. IPv4++) See also... http://www.netfilter.org/ Jim Fleming 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think... http://www.iana.org/assignments/ipv4-address-space http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt ----- Original Message ----- From: "Brian E Carpenter" <brian@hursley.ibm.com> To: "Tony Hain" <alh-ietf@tndh.net> Cc: <ngtrans@sunroof.eng.sun.com>; <ngtrans-chairs@sun.com>; <randy@psg.com>; "Philip J. Nesser II" <phil@Nesser.COM> Sent: Wednesday, August 14, 2002 11:12 AM Subject: Re: (ngtrans) WG Last Call on IPv4 Survey > So, is ngtrans submitting this document as its last gasp? I would hate to > see it lost. > > Brian > > Tony Hain wrote: > > > > This is an ngtrans working group last call for comments on advancing the > > following document as Informational: > > > > Title: Survey of IPv4 Addresses in Currently Deployed IETF Standards > > Author: Phil Nesser > > Document: draft-ietf-ngtrans-ipv4survey-02.txt > > > > Please send substantive comments to the ngtrans mailing list, and minor > > editorial comments to the author. > > > > This last call period will end two weeks from Monday on July 15, 2002. > > > > The ngtrans co-chairs, Tony / Alain / Margaret > ----- Original Message ----- From: "Randy Bush" <randy@psg.com> To: "NGtrans wg" <ngtrans@sunroof.eng.sun.com> Sent: Wednesday, August 14, 2002 10:05 AM Subject: (ngtrans) v6 considered operational > it is time for ngtrans to declare victory [0]. ngtrans has come > up with many tools, even more than were expected. but, as we saw > in yokohama, v6 is here. wgs don't go on forever. it is time to > declare victory for ngtrans and move forward. > > we now have to operate the combined net. this is a different job > than tool development, and should have a new, more operationally > oriented working group. new tools that are found necessary by the > operational and user communities should be developed in the > appropriate protocol wgs [1] as ipv6 spreads through the ietf > culture. and it is high time it spread through our technology > and culture. > > hence it is planned for ngtrans be closed and a new group, v6ops, > be chartered. i have appended a proposed charter for v6ops. your > comments would be appreciated. > > a number of high-order goals drove the decision to do it this way. > > o as we saw in yokohama, v6 is deploying today. it has become a > matter of operational concern, and not a guess as to what will > be needed if it ever is deployed. we need to think of it this > way ourselves, and the world has to know it (think press, etc) > > o v6 has been hiding in a corner of the ietf. with v6ops, we > hope to drive problems and tasks out into the appropriate wgs, > e.g. dns to dnsop and dnsext, mail to apps, etc. > > o we hope to make a sufficiently clean break that all documents > would be evaluated on their technical and operational merit, > without historical baggage good or bad. > > ngtrans did a great job preparing for the future. but the > combined v4/v6 network is no longer the future, it is today. now > we need to move on to operate it compatibly with the v4 network. > welcome v6ops. > > randy > > --- > > [0] - while a number of other iesg members and non-i* folk have > helped work this out, i an the area director and will take > any resulting pool-pah [2]. hence the use of the first > person. > > [1] - iff the appropriate protocol wg can not be found, then v6ops > may take on the work itself. but this is not the preferred > mode. this does not imply spinning up new wgs to do new > tool projects. > > [2] - see <http://www.cs.uni.edu/~wallingf/personal/bokonon.html>. > > --- > > IPv6 Operations (v6ops) > > Chair(s): > Margaret Wasserman <mrw@windriver.com> > Jun-Ichiro itojun Hagino <itojun@iijlab.net> > > Operations and Management Area Director(s): > Randy Bush <randy@psg.com> > Bert Wijnen <bwijnen@lucent.com> > > Operations and Management Area Advisor: > Randy Bush <randy@psg.com> > > Mailing Lists: > General Discussion: v6ops@ops.ietf.org > To Subscribe: Send mail to majordomo@ops.ietf.org, with "subscribe > v6ops" (no quotes) in the body of the message. > Archive: <http://ops.ietf.org/lists/v6ops/> > <ftp://ops.ietf.org/pub/lists/v6ops.*> > > Description of Working Group: > > The global deployment of IPv6 is underway, creating an IPv4/IPv6 > Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and > nodes. This deployment must be properly handled to avoid the division > of the Internet into separate IPv4 and IPv6 networks while ensuring > global addressing and connectivity for all IPv4 and IPv6 nodes. > > The IPv6 Operations Working Group (v6ops) develops guidelines for the > operation of a shared IPv4/IPv6 Internet and provides guidance for > network operators on how to deploy IPv6 into existing IPv4-only > networks, as well as into new network installations. > > The v6ops working group will: > > (1) Solicit input from network operators and users to identify > operational or security issues with the IPv4/IPv6 Internet, and > determine solutions or workarounds to those issues. This includes > identifying standards work that is needed in the IPv6 WG or in other > IETF WGs or areas and working with those groups/areas to begin > appropriate work. These issues will be documented in Informational > or BCP RFCs, or in Internet-Drafts. > > (2) Provide feedback to the IPv6 WG regarding portions of the IPv6 > specifications that cause, or are likely to cause, operational or > security concerns, and work with the IPv6 WG to resolve those > concerns. This feedback will be published in Internet-Drafts or > RFCs. > > (3) Publish Informational RFCs that help application developers (within > and outside the IETF) understand how to develop IP version- > independent applications. Work with the Applications area, and > other areas, to ensure that these documents answer the real-world > concerns of application developers. This includes helping to > identify IPv4 dependencies in existing IETF application protocols > and working with other areas and/or groups within the IETF to > resolve them. > > (4) Produce Informational or BCP RFCs that help network operators > understand and avoid common operational and security issues > encountered in IPv6-only and shared IPv4/IPv6 networks. > > (5) Publish Informational or BCP RFCs that identify potential security > risks in the operation of shared IPv4/IPv6 networks, and document > operational practices to eliminate or mitigate those risks. This > work will be done in cooperation with the Security area and other > relevant areas or working groups. > > (6) Publish Informational or BCP RFCs that provide viable solutions for > deploying IPv6 within common network environments, such as ISP > Networks (including Core, HFC/Cable, DSL & Dial-up networks), > Enterprise Networks, Unmanaged Networks (Home/Small Office), and > Cellular Networks. > > These documents should serve as useful guides to network operators > and users on how to deploy IPv6 within their existing IPv4 networks, > as well as in new network installations. > > (7) Assume responsibility for advancing the basic IPv6 transition > mechanism RFCs along the standards track, if their applicability to > common deployment solutions is demonstrated in (6) above: > > Transition Mechanisms (RFC 2893) > SIIT (RFC 2765) > NAT-PT (RFC 2766) > 6to4 (RFC 3056 & 3068) > > This includes updating these mechanisms, as needed, to resolve > problems. In some cases, these mechanisms may be deprecated > (i.e. moved to Historic), if they are not found to be applicable to > the deployment solutions described in (6) or if serious flaws are > encountered that lead us to recommend against their use. > > (8) Identify open operational or security issues with the deployment > solutions documented in (6) and fully document those open issues in > Internet-Drafts or Informational RFCs. The v6ops group will also > work to find workarounds or solutions to basic, IP-level deployment > issues that can be solved using widely-applicable transition > mechanisms, such as dual-stack, tunneling or translation. > > In the event that resolution of an open issue requires the > standardization of an additional, widely-applicable transition > mechanism, the v6ops group will work with our ADs to determine > whether to undertake that work within v6ops. > > IPv6 operational and deployment issues with specific protocols or > technologies (such as Applications, Transport Protocols, Routing > Protocols, DNS or Sub-IP Protocols) are the primary responsibility of > the groups or areas responsible for those protocols or technologies. > However, the v6ops group will provide input to those areas/groups, as > needed, and cooperate with those areas/groups in developing and > reviewing solutions to IPv6 operational and deployment problems. > > > Goals and Milestones: > > Aug 02 Publish Cellular Deployment Scenarios as a WG I-D > Aug 02 Publish Unmanaged Network Deployment Scenarios as a WG I-D > Aug 02 Publish ISP Deployment Scenarios as a WG I-D > Aug 02 Publish Cellular Deployment Solutions as a WG I-D > Sep 02 Publish Unmanaged Network Deployment Solutions as a WG I-D > Sep 02 Publish Enterprise Deployment Scenarios as a WG I-D > Oct 02 Publish ISP Deployment Solutions as a WG I-D > Oct 02 Submit Transition Mechanisms (Dual Stack & 6over4) to IESG for DS > Nov 02 Publish Enterprise Deployment Solutions as a WG I-D > Dec 02 Submit Cellular Deployment Scenarios to IESG for Info > Dec 02 Submit Cellular Deployment Solutions to IESG for Info > Feb 03 Submit Unmanaged Network Deployment Scenarios to IESG for Info > Feb 03 Submit Unmanaged Network Deployment Solutions to IESG for Info > Mar 03 Submit ISP Deployment Scenarios to IESG for Info > Mar 03 Submit ISP Deployment Solutions to IESG for Info > Apr 03 Submit Enterprise Deployment Scenarios to IESG for Info > Apr 03 Submit Enterprise Deployment Solutions to IESG for Info > > <More goals need to be added after consultation with authors/others> > > Internet-Drafts: > > Request For Comments: > > Network Address Translation-Protocol Translation (NAT-PT) (RFC 2766) > Stateless IP/ICMP Translation Algorithm (SIIT) (RFC 2765) > Transition Mechanisms for IPv6 Hosts and Routers (RFC 2893) > Connection of IPv6 Domains via IPv4 Clouds (RFC 3056) > An anycast prefix for 6to4 relay routers (RFC 3068) > > -30- > >