A Direction for IPng
How to organize the effort to pick the next version of IP
Gross, P., "A Direction for IPng", RFC 1719, DOI 10.17487/RFC1719, December 1994, <https://www.rfc-editor.org/info/rfc1719>.
@misc{rfc1719,
series = {Request for Comments},
number = 1719,
howpublished = {RFC 1719},
publisher = {RFC Editor},
doi = {10.17487/RFC1719},
url = {https://www.rfc-editor.org/info/rfc1719},
author = {P. Gross},
title = {{A Direction for IPng}},
pagetotal = 6,
year = 1994,
month = dec,
} RFC text
Contents
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)."
"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.
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.
- 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.
(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
AI ELI5
On this page
§1Introduction
After a 1994 IETF meeting in Amsterdam, the community held a special meeting called the IPDecide BOF to discuss choosing the next generation of IP. The meeting showed that while the community recognized the need for a new IP protocol, there was no clear consensus on how to make the decision or what criteria to use. The community was uncertain about the urgency of the problem and whether the IETF or the marketplace should make the final choice.
Engineers knew they needed a new internet address system, but did not agree on how to pick it.
§2A Direction for IPng
The RFC announces key decisions about the IPng process. The IETF will move toward closure by taking active steps toward a technical decision, rather than waiting for market forces. The IESG (Internet Engineering Steering Group) will take responsibility for developing an IPng recommendation. The process will be open and published well in advance. The community will have ample opportunity to review and comment on the recommendation before it is finalized.
A new temporary IESG area is created specifically for IPng, with two co-Area Directors: Allison Mankin from NRL and Scott Bradner from Harvard. An IPng Directorate will act as a direction-setting body to bring additional viewpoints into the process. All existing IPng-related working groups are moved into this new area.
The leaders decided to set up a team that will gather information and make a recommendation to the community.
§3Key Issues to Resolve
Two critical issues must be addressed before making an IPng recommendation. First, the scope question: should IPng address only known scaling and address exhaustion problems, or should it also include advanced features like resource reservation for real-time traffic? Advocates for including advanced features argue that migrating to a new IP happens only rarely and all advanced features should be considered. Opponents argue that time pressure from address exhaustion may not allow full exploration of advanced features.
Second, the timeframe question: how urgent is the need for IPng? The answer depends on the current rate of address assignments, address assignment policies, the impact of CIDR aggregation, the time needed to develop IPng, and the time required to deploy and migrate to the new protocol.
The team needed to decide two things: what should the new system do, and how much time do we have to build it.
§4Work Plan
The RFC outlines specific activities for the new Area Directors and Directorate. They must develop an understanding of the available timeframe by reviewing Internet growth metrics, analyzing the impact of CIDR address aggregation, developing guidelines for classless Internet addressing, and estimating the time required for development, deployment and migration. Based on this timeframe analysis, they will make a recommendation on IPng scope: whether to focus on scaling issues alone or include advanced features.
The team will also develop a clear set of technical requirements and decision criteria for IPng (building on the IESG statement in RFC 1380) and make a recommendation on which current IPng candidates to accept, if any. Regular progress reports are required, with a detailed report at the next IETF plenary.
They will collect data about when we will run out of addresses, decide what features to include, write down the rules for judging proposals, and then pick the winner.