IP"NG" and IPv6 are not the same thing....

["Jim Fleming" <[e-mail]>]

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" <[e-mail]>
To: "Tony Hain" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>; "Philip J. Nesser II" <[e-mail]>
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" <[e-mail]>
To: "NGtrans wg" <[e-mail]>
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 <[e-mail]>
>   Jun-Ichiro itojun Hagino <[e-mail]>
>
> Operations and Management Area Director(s):
>   Randy Bush <[e-mail]>
>   Bert Wijnen <[e-mail]>
>
> Operations and Management Area Advisor:
>   Randy Bush <[e-mail]>
>
> Mailing Lists:
>   General Discussion: [e-mail]
>   To Subscribe: Send mail to [e-mail], 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-
>
>