1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc1719.txt b/doc/rfc/rfc1719.txt
new file mode 100644
index 0000000..083d6ea
--- /dev/null
+++ b/doc/rfc/rfc1719.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+RFC 1719                  A Direction for IPng             December 1994
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gross                                                           [Page 6]
+