path: root/doc/rfc/rfc1719.txt

Network Working Group                                           P. Gross
Request for Comments: 1719                                           MCI
Category: Informational                                    December 1994


                          A Direction for IPng

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   This document was submitted to the IPng Area in response to RFC 1550.
   Publication of this document does not imply acceptance by the IPng
   Area of any ideas expressed within.  Comments should be submitted to
   the big-internet@munnari.oz.au mailing list.  This RFC specifies
   criteria related to mobility for consideration in design and
   selection of the Next Generation of IP.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1
   2.   A Direction for IPng . . . . . . . . . . . . . . . . . . . . 2
   3.   Issues Toward IPng Resolution. . . . . . . . . . . . . . . . 3
   4.   Security Considerations. . . . . . . . . . . . . . . . . . . 5
   5.   Author's Address . . . . . . . . . . . . . . . . . . . . . . 5

1. Introduction

   At the Amsterdam IETF meeting, we held a BOF, entitled the "IPDecide
   BOF", on the process and progress of the IPng activities.

   ("IPng" stands for "IP, the next generation".   The IPDecide BOF was
   chaired by Brian Carpenter.  Minutes are available in the IETF
   directories, with the file name </ietf/93jul/ipdecide-minutes-
   93jul.txt>.)

   The IPDecide BOF explored several facets of the IPng process, such
   as:

      "What is the basis for choosing the next generation IP (i.e., what
      are the technical requirements and decision criteria)."






Gross                                                           [Page 1]
^L
RFC 1719                  A Direction for IPng             December 1994


      "With the advent of CIDR and new, more stringent address
      assignment policies, are we comfortable that we truly understand
      the level of urgency?"

      "Should the IETF or the marketplace make the final IPng decision".

   The BOF was held in a productive atmosphere, but did not achieve what
   could be called a clear consensus among the assembled attendees.  In
   fact, despite its generally productive spirit, it did more to
   highlight the lack of a firm direction than to create it.

   The IPDecide BOF was followed the next evening by the open IESG
   plenary. During this session, the IESG and the assembled attendees
   discussed the IPng issues and seemed to arrive at a consensus based
   on the following set of bullets presented by the IETF chair:

      "The IETF needs to move toward closure on IPng."  That is, the
      IETF should take active steps toward a technical decision, rather
      than waiting for the "marketplace" to decide.

      "The IESG has the responsibility for developing an IPng
      recommendation for the Internet community."  That is, the IESG
      should provide leadership and take specific actions to help move
      the IETF toward a technical decision.

      "The procedures of the recommendation-making process should be
      open and published well in advance by the IESG."

      "As a part of the process, the IPng WGs may be given new
      milestones and other guidance to aid the IESG."

      "There should be ample opportunity for community comment prior to
      final IESG recommendation (e.g., there will be an extended Last
      Call)."

2. A Direction For IPng

   Building on this consensus, I'd like to announce a set of specific
   directions in the IESG that I hope will move us toward timely
   resolution of many of the key IPng issues.

   The IESG will establish a temporary, ad hoc, "area" to deal
   specifically with IPng  issues.  The charter for this new IESG area
   is to develop a recommendation on which, if any, of the current
   proposals should be adopted as the "next IP".  This recommendation
   will be submitted to the IESG and to the Internet community for
   review.  Following an adequate period of review to surface any
   community concerns, the IESG will issue a final IPng recommendation.



Gross                                                           [Page 2]
^L
RFC 1719                  A Direction for IPng             December 1994


   All of the current IPng-related working groups will be moved
   immediately into this new area.

   This new area will be headed by two co-Area Directors from within the
   IESG. I have asked Allison Mankin (NRL), current Transport Services
   AD, and Scott Bradner (Harvard), current Operational Requirements AD,
   to serve as co-AD's for this temporary area.  I am very pleased to
   report that they have agreed to take this important assignment.
   (Because this is expected to be a temporary assignment, Scott and
   Allison will also continue to serve in their current IESG positions
   during this period.)

   All IETF Areas are now expected to have Area Directorates.  For the
   IPng Area, a Directorate will be especially important to bring
   additional viewpoints into the process.  Therefore, I am asking that,
   as their first action, Scott and Allison form a specific IPng
   Directorate to act as a direction-setting and preliminary review
   body.  The IPng process will continue to be completely open, and
   therefore reports and meeting notes from any IPng Directorate
   meetings will be published in timely fashion.

3. Issues Toward IPng Resolution

   Two important issues need resolution immediately before we can expect
   progress toward an IPng recommendation:

      - What is the scope of the effort?

      That is, should IPng be limited to solving the well known scaling
      and address exhaustion issues; or should IPng also include
      advanced features such as resource reservation for real-time
      traffic?

      The argument in favor of considering advanced features is that
      migration to a new IP is (hopefully, only!) a once-in-a-generation
      occurrence, and therefore all advanced features should at least be
      considered.

      Arguments opposed to considering advanced features include the
      fact that we may not have time for this level of effort before the
      scaling and address exhaustion problems confront us, and that we
      may not have the necessary understanding and experience to make
      all the correct choices at this time.








Gross                                                           [Page 3]
^L
RFC 1719                  A Direction for IPng             December 1994


      - What is the available timeframe?

      That is, before we can even begin to make an informed decision
      about the scope, we need a better understanding of the urgency and
      time constraints facing us.

      Factors that affect the available time include the current rate of
      address assignments (which can give us an estimate of when we are
      currently projected to run out of addresses), the current policies
      governing address assignment (which can give us an understanding
      of how policies affect the assignment and utilization rates), the
      impact of CIDR aggregation, the development time for IPng, and the
      time needed to field and migrate to the new IPng.

   Therefore, I am asking the new AD's and the Directorate to start
   immediately the following specific activities to help guide their
   ultimate IPng recommendation:

      1. Develop an understanding of the available timeframe, covering
      at least the following issues:

         - Review Internet growth metrics, such as the current address
         assignment and utilization rates.  Develop an understanding of
         how the new address assignment policies impact the assignment
         and utilization rates.

         - Review the expected impact of CIDR address aggregation.
         Develop an understanding of the expected savings due to CIDR
         aggregation.

         - Develop new technical guidelines for classless Internet
         addressing.  Specific examples include guidelines for how to
         utilize variable length subnet masks, and how to utilize
         currently unused Class A and B addresses in a classless fashion
         in hosts and routers.

         - Develop a strong understanding of the time required for the
         development, fielding, and migration for a new IP.

         - Based on all the above issues,

            (a) develop an estimate for how long we have to develop
            and deploy an IPng.  This could be a set of estimates
            based on best/worst case estimates for how each of the
            above factors will affect the available timeframe.






Gross                                                           [Page 4]
^L
RFC 1719                  A Direction for IPng             December 1994


            (b) Consider whether more stringent assignment policies
            might provide additional time.  If so, recommend such
            policies.

            (c) make a recommendation on whether it is worthwhile to
            mount a serious effort to reclaim addresses and/or to
            renumber significant portions of the Internet.

      2. Based on an informed judgment of the time constraints above,
      make a recommendation regarding the scope for IPng, i.e., should
      IPng consider scaling issues only or advanced topics also.

      3. Based on the scope and time constraints, develop a clear and
      concise set of technical requirements and decision criteria for
      IPng.  These should include, but not be limited to, the criteria
      outlined in the IESG statement (RFC1380).

      4. Based on the decision criteria, scope, and time constraints,
      make a recommendation on which of the current IPng candidates to
      accept, if any.

      Finally, I am asking Scott and Allison to make a detailed report
      at the opening plenary of the next IETF meeting in November on the
      status of setting up their new area, and on their progress toward
      organizing the above work items.  In particular, the status of the
      work items on timeframe should be fully reported. This will be
      followed by regular progress reports to the Internet community, at
      IETF meetings and in other appropriate forums.

   Please join me in giving Scott and Allison our full cooperation, and
   in thanking them for accepting this daunting assignment.  I feel
   confident that we will now make significant progress on the important
   IPng issues facing the Internet community.

4. Security Considerations

   Security issues are not discussed in this memo.

5. Author's Address

   Phill Gross
   Director of Internet Engineering
   MCI Data Services Division
   2100 Reston Parkway FL 6
   Reston, VA   22091

   Phone: 703-715-7431
   EMail: phill_gross@mcimail.com



Gross                                                           [Page 5]
^L
RFC 1719                  A Direction for IPng             December 1994





















































Gross                                                           [Page 6]
^L