Minutes of IAB Meeting — October 11, 1990
InterOp ’90, San Jose, CA
FOREWARD
The meeting agenda will be found in Appendix A. The attendees were:
IAB Members:
-
Bob Braden, ISI
Hans-Werner Braun, Merit
Vint Cerf, NRI
David Clark, MIT
Phill Gross, NRI
Steve Kent, BBN
Barry Leiner, ADS
Dan Lynch, Interop
Jon Postel, ISI
FNC Visitors:
Paul Mockapetris, DARPA
Guests for specific topics:
-
Michael Baum, RSADSI
Noel Chiappa, MIT
Steve Deering, Xerox PARC
Dave Katz, Merit
Jeff Mogul, DEC
Scribe:
Ron Frederick, Stanford
These minutes were prepared by Ron Frederick of Stanford and edited by Bob Braden, the IAB Executive Director (ExecD). We have endeavored to accurately reflect the content and thrust of the discussions. Although the IAB has reviewed the results, we must take responsibility for any unintentional misrepresentation.
-
Bob Braden
Ron Frederick
1. REVIEW ACTION ITEMS
- Gross has collected data from IETF members about which working groups they are active in, but this data has not yet been sum- marized in a report. A report should be available at the Janu- ary meeting.
- Cerf has not yet sent letters to vendors regarding the condi- tions under which vendor proprietary protocols can become Inter- net standards. Some additional discussion is still needed on this matter.
- Gross has taken over the Leiner action to publish the charter and ethics statements of the CCIRN as an RFC.
- Cerf’s action to write down a description of the IAB standards process has been moved to the PWG (Policy Working Group) action list.
A detailed list of old action items will be found in Appendix B. The following significant points emerged:
NEW ACTION: ExecD: Check whether any earlier action items for the PWG have fallen through the crack.
2. IETF REPORT — GROSS
- Craig Partridge, previously in charge of the Host and User Ser- vices area, has been made an at-large member of the IESG. The User Services working group has been elevated to area status, with its chairperson Joyce Reynolds joining the IESG as area director. The “Host” portion of the former area will be absorbed by the Applications area and by converting the IP area into a TCP/IP area.
- Dave Crocker has moved into a new position on the IESG, to be concerned with IETF standards procedures. His first task will be to document the current standards procedures. He will also write the standards section of the IETF Handbook that is in preparation, working closely with the IAB with respect to the part of the procedures in which the IAB is involved. IAB members were encouraged to share their views with Dave. Braden suggested that Dave be included in the PWG discussions of IAB standards procedures.
- A Network Management review board is being formed to deal with the large amount of work involved in reviewing the number of new MIBs being written today. Because of the current composition of the committee, it will be called the SNMP Network Management Directorate. A corresponding board will be formed for CMOT when its standardization reaches the point where such a board is appropriate.
- Mats Brunel from the Swedish Institute for Computer Science (SICS) will chair the IETF Operations board. This was noted as a very helpful step towards international expansion of IETF activity.
- The IESG will now meet monthly, mostly by telephone conference, and each area director has been asked to produce an “area plan” within the next five weeks. The intent is to produce a document for IAB comment before the January 1991 meeting.
- Every future IESG recommendations to the IAB with respect to Internet standards will include a “technical summary”.
Gross reported that his latest annual review of the IESG (Internet Engineering Steering Group) has led to the following changes:
Gross did not report on technical issues or standards actions, except to indicate that all future IETF monthly reports will contain a list of those actions.
He pointed out that Internet Draft activity has reached the level of 2-3 new or revised documents every week, and that some interesting stuff is going on. He said that Greg Vaudreuil, the IESG secretary, is responsible for tracking the age of Internet Drafts, to enforce the 6 month timeout rule.
Cerf suggested that the IAB needs to draw up its vision for the direction of the Internet, for input to the IESG, and that this might take the form of a replacement for IEN-48 [“The Catenet Model of Internetworking”, V. Cerf, July 1978].
3. IAB POLICIES
- SNMP is the de facto standard for managing TCP/IP using TCP/IP.
- CMIP is the standard for managing OSI using OSI.
- In the mixed cases, people have a choice.
3.1 Network management policy regarding SNMP/CMIP/CMOT
Cerf observed that reality has overrun the IAB policy on network management protocols that was presented in RFC-1052 [“IAB Recom- mendations for the Development of Internet Network Management Standards”, V. Cerf, April 1988]. This policy recommended SNMP as a short term solution and a long-term solution based upon the OSI CMIP protocol. SNMP has become the de facto standard for TCP/IP network management. Although CMOT (CMIP over TCP) has not yet made it through the standards process, CMIP is the standard for managing the OSI parts of the multi-protocol Internet.
Concern was also raised over the multiplicity of MIBs. The IAB originally asked for a single MIB for both protocols, but since the semantics of SNMP and CMIP are different, in some cases it became necessary to allow different MIBs.
Braden and Gross suggested setting up a meeting or workshop to recommend future directions for network management. Chuck Davin, IESG area director for Network Management, should play a key role.
Leiner proposed the position:
It was agreed that the PWG should produce the first draft of a policy statement based upon this idea.
NEW ACTION: Leiner: Ask the PWG, with help of Chuck Davin, to draft a possible IAB statement about the present situation and possible future directions for network management.
3.2 X.500 policy
The question was raised whether the IAB should make a policy statement recommending the use of X.500 in the Internet, including the reasoning behind it.
Mockapetris pointed out that simply recommending X.500 might not be enough. Crucial questions include what information is to be kept in X.500, how will it be used, and who is going to administer the database. He suggested that we need to choose our applica- tions and to develop a corresponding information architecture. Until X.500 performance is sufficient, it will be impossible to replace the DNS with X.500; however, X.500 should be useful for high-level human name lookups (“white pages” service).
Gross noted that there is already an IETF working group on X.500, chaired by Steve Kille.
NEW ACTION: Gross: Ask Steve Kille to take Braun’s draft of the X.500 RFC and add a rationale section to it.
3.3 Acceptable use policy
The question was raised whether any further IAB action is needed towards implementation of the policies recommended in RFC-1174 [“IAB Recommended Policy on Distributing Internet Identifier Assignment and IAB Recommended Policy Change to Internet ‘Con- nected’ Status”, V. Cerf, August 1990], and accepted by the Federal Networking Council (FNC).
It was noted that the NIC has taken the first steps to implement the new policies, but they have sought input from the IAB on the taxonomy of “acceptable use”, whose specification will replace US government agency sponsorship as a criterion for connection. Elise Gerich (Merit) and Jon Postel (IANA) have been working on the mechanisms. The international case is difficult. Postel noted that many federal agencies are reluctant to publish their acceptable use policy.
NEW ACTION: Postel: Try get all acceptable use policies pub- lished.
A distinction was made between acceptable use of a network and acceptable use of a mailing list. In the case of a mailing list, it makes sense to let the members of the list decide upon what is acceptable. Anyone who violates the common agreement is likely to get a blast of flames that should discourage future violations. Of course, mailing list usage is still subject to the rules imposed by the networks transporting the traffic.
It was emphasized that the IAB is not, and cannot be, a policeman on acceptable use. However, it may be useful for the IAB to draft a statement that describes the cultural norms and makes the net- work vs. mailing list distinction, for example, based upon our earlier statement on ethical usage.
NEW ACTION: Cerf: Draft an RFC containing general recommenda- tions about acceptable use of services such as mailing lists.
Another acceptable use issue was whether profit-making companies can be allowed to use the Internet. Some felt this should be allowed without restriction, although the present NSFnet backbone policy requires traffic to be “in support of scholarly and scien- tific activity”. Commercial services have been approved on an individual basis. It was noted that the new backbone organization ANS will allow any traffic that the IRS considers R&D, which includes commercial product development.
Billing users is a serious concern, given the present state of Internet authentication.
NEW ACTION: Kent: Send the IAB his write-up on login authenti- cation.
4. ARCHITECTURE
- “Probes” are sent only when there is data to send. Note that there is no such thing as a separate “probe packet”; the data packets themselves serve as the probes.
- Probe packets are never larger than the first-hop MTU.
- The most likely place for a probe to be bounced (causing ICMP traffic) is where it would be forwarded from a campus network to a regional or backbone network; thus, most of the probe and ICMP traffic will never be seen on the regional or back- bone nets.
- Make more Class B Addresses
Stealing half of the class A addresses for use in class B would extend the 1994 date to 1998. That would only be a delaying tactic, and it was unclear exactly how long a delay would be “long enough.”
- Reformat 32-bit addresses and reallocate them in a denser fashion.
- Allow IP addresses to be non-unique globally.
- Define new IP header format.
If we are going to change the IP header format for any rea- son, we should expand the addresses from 32 to 64 bits.
- Introduce a new, integrated routing and addressing mechanism.
Chiappa suggested making a 32-bit IP address into a UID, or handle, that would be mapped by the gateways into an extended routing address. He suggested that this would avoid changing hosts, and it would allow us to fix the problem that an IP address labels an attachment point rather than a host itself. If we ran out of 32-bit UIDs, we could make them local or expand them to 64 bits.
- Use OSI IP.
Deering, Katz, and Chiappa arrived for this section of the agenda. Mogul was slightly delayed, so the discussion of NSAP address syntax was pushed ahead of MTU discovery.
4.1 NSAP Address Syntax and Semantics
Dave Katz of Merit discussed his memo (see Appendix C) concerning the possible ways to assign NSAP addresses in the Internet, from the viewpoint of the NSFnet backbone.
For example, NSF has a portion of the address space, but addresses could also be assigned by other US authorities or other interna- tional authorities. Can the present routing scheme handle that? Katz answered “yes”; presently routing is done by a longest-prefix match in a table. This table is currently static, but will even- tually be managed by IDRP.
Administration of the space is hierarchical, with ISO/CCITT at the top, individual countries below that (with ANSI handling the US), and then organizations below that. One danger of that scheme is that you don’t want to give out a large number of organizational identifiers, as that would mean a huge, flat address space.
One suggestion is that carriers be organizations, which would mean that any host that uses multiple carriers would have multiple addresses. Some felt that past experience suggests this to be a bad idea. An alternative discussed was to make the assignments geographically. While this looks much more attractive than carrier-specific addresses, it also seems like a hard problem.
One final question was whether anyone is keeping track of address assignments. Presently, each administrative authority keeps track of the assignments it makes, but this information is not collected anywhere, and in fact it is unclear exactly how public some of that information is.
It was suggested that name-to-NSAP mappings be kept in the DNS, although Mockapetris noted that X.500 supporters tend to oppose the use of the DNS for any new purpose, particularly when OSI related.
There was no conclusion from this discussion.
4.2 MTU Discovery
The IESG earlier recommended to the IAB that the results of the MTU Discovery Working Group be entered into the standards track as a Proposed Standard. Several IAB members then raised significant questions about the proposal. Although subsequent meetings had apparently settled these issues, the topic was introduced at the IAB meeting to make sure everyone was satisfied.
Deering discussed briefly a rejected alternative, using routing protocols to provide MTU information. He pointed out that this violates the information hiding requirements of scalable routing. On the other hand, if a router along a path does know an upper bound on the MTU to the destination, it can reject the packet at that point, returning what it knows the upper bound to be.
To deal with the high rate of change of routes in the Internet, the protocol is designed to respond to bad information quickly while taking longer to respond to good information. Therefore, a flapping route would not necessarily cause repeated MTU changes.
Mogul has a 4.3BSD implementation of this protocol and Van Jacob- sen is integrating the code into 4.4BSD. Initial testing shows that it works, but there is little actual experience with it.
Finally, there was concern about the amount of traffic caused by “probes”. Two responses were given by Deering and Mogul:
It was agreed to add to the specification a hard-coded lower bound on the probe time constant.
The IAB then agreed to make the MTU discovery proposal a Proposed Standard.
4.3 IP Address Space
Noel Chiappa, as the IESG Area Director for Internet Services, made a presentation about IP address space limitations. Appendix D contains a background summary provided by Phill Gross.
Chiappa argued that we should plan on the assumption that the IP- based Internet will continue to grow indefinitely. OSI usage could grow fast enough to solve the problem of exponential growth, but we should not depend on this escape from Internet scaling problems.
The growth rate of NSF connected networks seems to closely fit an exponential curve, doubling every 7.6 months. Class B addresses in particular are being used up at a rate that causes the assigned space to double every 14 months. This suggests that the NIC will run out of class B addresses to assign in 1994, and that all these networks could be connected and in the routing tables by 1997. Even if we are past the “rollover” or saturation point in the growth of academic networking (an arguable point), the continued expansion of commercial and international connectivity are expected to continue the exponential growth pattern for some time.
The discussion concerned the number of networks. It was observed that another important issue is the increase in the number of hosts on (subnetted) networks, and that this may require variable-length subnetting.
Chiappa commented that running out of network addresses shouldn’t be the primary concern. Before that happens, it is likely that the network will experience routing collapse. Even OSPF is only likely to be able to handle 10,000 networks. Chiappa discussed a number of classes of solutions.
Clark suggested another alternative: architected application-level addresses, which could be translated into non-unique IP addresses. These would be roughly equivalent to email addresses.
Chiappa expressed a personal preference for (5), and indicated he has an uncompleted paper on this subject. Since many details of the scheme are unclear, the IAB strongly encouraged Chiappa to complete the paper and to submit it for publication in the ACM Computer Communication Review (CCR).
Mockapetris observed that both the UID and the corresponding route address could be obtained from the DNS; hence, the route address would be cached and available in the name server local to the host, and hence the router, that would need it. Deering was con- cerned that dependence upon the DNS would threaten IP robustness, but Clark pointed out that this could be solved by hosting name servers and routers in the same systems.
Kent pointed out the advantages of globally unique addresses for security considerations.
5. IAB ORGANIZATION
5.1 New members
A desire was expressed to make the membership of the IAB more international in scope. In addition, it seemed important to keep in mind the issue of supporting multiple protocols. One question that arose was how to assemble a list of international candidates. Asking some of the international organizations to recommend a list of candidates was presented as an option. Specific proposals led to concern about political implications of each.
Other efforts toward internationalization are proceeding. The IETF now has an international member on the Operations board, and the operations area as a whole could become an international effort. It would be helpful to schedule more Internet events that include international participation.
Braun expressed a concern that the longer the IAB waits, the harder it will be to change the perception that the IAB is US- centric. It was agreed that the IAB would make an internal com- mitment to choose an international member at the January meeting. In addition, it was agreed that efforts toward internationaliza- tion should be more aggressively publicized.
One final issue raised was about possibly limiting the tenure of service for IAB members. Gross pointed out that this was currently being planned for the IESG, though no specifics have been worked out yet.
5.2 ANSI affiliation
Two primary options for ANSI accreditation are either as a stan- dards committee or as an organization which, among other func- tions, makes standards. The latter option seems more appropriate for the IAB/IETF; however, it would require the existence of a “real” organization with a visible means of support.
Cerf suggested that a non-profit corporation could be found to act as the “secretariat” for IAB standards. This non-profit would satisfy ANSI concerns about stability, and it would be accredited by ANSI to assure that ANSI procedures were followed in the con- duct of IAB standards-making activities.
Due to time constraints, no specific decisions were made.
5.3 International Internet Consortium
This topic was deferred to a later meeting, for lack of time.
6. OTHER ISSUES
6.1 Response to OTA
OTA (the Whitehouse Office of Technology Assessment) has invited contributions about the NREN. A suggestion was made to submit Cerf’s RFC-1167 [“Thoughts on the National Research and Education Network”, V. Cerf, July 1990], after the other IAB members reviewed it. It was decided that a more in-depth document might be worthwhile.
NEW ACTION: IAB: Review RFC-1167.
NEW ACTION: Cerf: Write a more in-depth version of the existing RFC on the NREN for later OTA submission.
6.2 RSADSI Agreement Draft
RSADSI (RSA Data Security, Inc.) has drafted a contract that they will expect organizations to sign in order to become certifying authorities for distributing certificates for PEM (privacy- enhanced mail). Michael Baum, a lawyer hired by RSADSI to draft the agreement, joined the meeting for this discussion. Steve Crocker, area chair of the IESG for privacy and security, was unable to attend.
It was suggested that the IAB should publish this document soon, as an example of what organizations might expect. In addition, RSADSI is eager for input on any concerns people have about it in its present form.
Steve Crocker had previously raised his concern that certificates should be associated with individuals rather than being issued through organizations; if someone changes organizations, they might lose the ability to properly identify themselves. Crocker believes that certificates should be personal, like birth certifi- cates. However, there was not strong support for this viewpoint in the meeting. It was felt that the scheme allows either, and it seems sensible to proceed with organizationally-bound certificates to get the system started; individual certificates can always be issued later.
Kent explained that the scheme allows for certificates to be issued in two forms. The first asserts that the individual is directly affiliated with the issuing organization, while the second says that the issuer is simply acting as a notary and that no other affiliation should be assumed. The latter case allows personal certificates, although he noted that notaries do not offer the same level of assurance about the identity of the indi- vidual that a corporate issuer provides. He noted that someone with more than one organizational affiliation, or who has changed affiliation, can get more than one certificate with the same key pair.
There were no further objections, and it was agreed that the con- tract form as finalized by RSADSI will be published for public scrutiny and comment.
7. FUTURE MEETINGS
The following meetings are presently planned:
Phone Conferences:
-
Wed Nov 7 1:30-3:00 PM ET
Mon Nov 19 3:00-4:30 PM ET
Thu Dec 13 1:30-3:00 PM ET
Alternate dates, available for PWG:
-
Thu Nov 1 1:30-3:00 PM ET
Thu Nov 15 1:30-3:00 PM ET
Tue Nov 27 1:30-3:00 PM ET
Full Meetings:
-
ISI – Jan 8-9, 1991 (IESG on Jan 9)
Video – Apr 1, 1991
Ann Arbor – July 1-2, 1991
Interop – Oct 10, 1991
In addition, those IAB members who are able to attend the December IETF meeting in Boulder will meet jointly with the IESG and some international folks at a time to be determined.
8. DINNER MEETING
- Dr. Valeri Udalov
Deputy Director
Institute of Electronics and Computer Science
Latvian Academy of Sciences, USSRDr. Udalov is also the Scientific Secretary (Technical Director) of the Council of Akademnet, the Soviet equivalent of the late ARPANET.
- Dr. Daniel Josef Bem
Professor
Technical University of Warsaw - Dr. Laszlo Csaba
Head of Laboratory
Computer and Automation Institute
Hungarian Academy of Sciences
The IAB held a dinner meeting with visitors from Hungary, Poland, and the USSR:
In addition, Dave Caulkins, Executive Director of GLASNET, attended.
APPENDIX A — MEETING AGENDA
- IESG Changes
- Technical issues
- WG and standards actions since last IAB meeting
- Network management policy — replace RFC-1052?
- X.500 policy
- Acceptable use policy
- Cooperative MIB development
- MTU Discovery [guests: Deering, Mogul]
- NSAP Address syntax and semantics [guest: Katz]
- IP address space [guest: Chiappa]
- New members
- ANSI affiliation
- International Internet Consortium (IIC)
- Response to OTA
- Review internationalization — what additional actions needed?
- RSADSI Agreement draft [Kent, Michael Baum, Steve Crocker]
- Phone/video conferences
- January 8-9, 1991 at ISI.
- ????
IAB MEETING AGENDA
OCTOBER 1990
Interop ’90: Fairmont Hotel, San Jose, CA
THURSDAY OCTOBER 11, 1990
9:00 IETF Report — Gross
10:00 IAB Policies
12:00 [Lunch] Architecture
14:00 IAB Organization
[15:00 Break]
16:00 Other Issues
16:30
17:20 Future Meetings
17:30 Adjourn.
APPENDIX B: ACTION ITEM DISPOSITION
The following list shows the status of action items after the June 1990 IAB meeting.
Completed Actions from Previous Meetings:
DONE: Cerf: File claim for Internet name with trademark office.
DONE: Cerf: Invite OSFers to IETF.
DONE: Gross: Send 5 copies of the IETF Proceedings to each of the chairs of RARE and CCIRN.
DONE: Gross: Add a “How to Order IETF Proceedings” section to the IETF proceedings.
DONE: Braden: Summarize E2E RG work on architecture limits for IAB.
DONE/OBE: Gross: Present to the Engineering and Operations Work- ing Group (EOWG) of the FNC the IAB recommendations on changes to connected status and on distributed IP network number assignments.
DONE: Gross: Get statistics on the rate of IP network number con- sumption by class.
DONE: ExecD: Put on next IAB meeting agenda a further discussion of the IP address space problem.
DONE: Gross: Encourage Noel Chiappa to release the results of the Hale and Dorr liability studies.
DONE: Kent: Get current RSADSI agreement text for IAB review.
DONE: Braun: Ask Dave Katz to prepare writeup on NSAP situation.
DONE: Braun: Formulate proposed IAB statement on X.500 as a stra- tegic direction.
DONE: Cerf: Tell Larry L that IAB will support NET ’91.
DONE: Gross: Send email to IAB summarizing his efforts to move network management forward.
Continuing Actions from Previous Meetings:
ACTION: Cerf: Write up concerns on Operational Infrastructure.
ACTION: Gross: Report on IETF members for a list of WG’s in which they are active.
ACTION: Gross/Vaudreuil: Send message to IAB on how to use IETF WG database.
ACTION: Gross: Finish RFC on policy for connections from other countries to US Internet.
ACTION: Postel: Draft “Principles of the Internet [Architecture?]” document.
ACTION: Cerf: Send letter to Sun and Microsoft explaining require- ments for Internet standards.
ACTION: Gross: Publish the charter (“Terms of Reference”) and ethics statements of the CCIRN as an RFC.
ACTION: Lauck: Report on status of OSI registration procedures and authorities.
ACTION: Lauck: Write down the actions that the IAB could take on testing.
ACTION: Lynch: Write to COS to encourage their participation in IETF and their suggestions for joint projects.
ACTION: Kent: Provide a document specifying the configuration needed to run the PEM software.
ACTION: Gross: Ask IESG for document describing subset of BGP that is currently being implemented.
ACTION: Cerf: Get a note from Microsoft that the Lan Manager MIB effort is accepted and supported.
ACTION: Leiner: PWG write down description of IAB standards pro- cess.
ACTION: Cerf: Form a working party to construct strawman bylaws for proposed International Internet Consortium.
ACTION: ExecD: Send out list of IETF areas and gather signups from IAB members for standards interest.
NEW ACTION : ExecD: Check whether any earlier action items for the PWG have fallen through the crack.
NEW ACTION: Leiner: Ask the PWG to draft a possible IAB statement about the present situation and possible future directions for network management, with the help of Chuck Davin.
The following new actions were added:
NEW ACTION : ExecD: Check whether any earlier action items for the PWG have fallen through the crack.
NEW ACTION: Leiner: Ask the PWG, with help of Chuck Davin, to draft a possible IAB statement about the present situation and possible future directions for network management.
NEW ACTION: Gross: Ask Steve Kille to take Braun’s draft of the X.500 RFC and add a rationale section to it.
NEW ACTION: Postel: Try get all acceptable use policies published.
NEW ACTION: Cerf: Draft an RFC containing general recommendations about acceptable use of services such as mailing lists.
NEW ACTION: Kent: Send the IAB his write-up on login authentica- tion.
NEW ACTION: IAB: Review RFC-1167.
NEW ACTION: Cerf: Write a more in-depth version of the existing RFC on the NREN for later OTA submission.
APPENDIX C — USING OSI NSAP ADDRESSES IN THE INTERNET
The following information on the use of OSI NSAP addresses in the NSFNET Backbone was supplied by Dave Katz of Merit.
The NSFNET has been assigned a GOSIP Administrative Authority Identifier (AAI) from which to assign addresses within the NSFNET backbone network. The plan is to use the GOSIP address structure, which is as follows:
(field) AFI IDI DFI AAI RES RD AREA ID NSEL
(octets) 1 2 1 3 2 2 2 6 1
- The AFI is ISO ICD, binary abstract syntax DSP (47).
The IDI is US Government (0005).
The DSP Format Identifier (DFI) is hexadecimal 80.
The AAI for the NSFNET backbone is hexadecimal FFFF00.
The REServed field is 0000.
As an aside, note that this GOSIP format differs from the one proposed by ANSI. The ANSI space comes from the US DCC (data country code) space, while the GOSIP space comes from the ICD (International Code Designator) part of the tree. The ICD space is intended for administrations that are international in scope; three well-known values assigned are for OSInet (an X.25-based network that the vendors use for interoperablility testing), the US Government, and the US DoD. The ANSI format has the fields:
DCC / US / <Org Id> / <undefined>
which leaves the low-order part up to the organization that owns the space.
The following Routing Domain (RD) values are to be assigned for the NSFnet Backbone:
0001 Current NSFNET T1 backbone
0002 New NSFNET T3 backbone
FFFF Current NSFNET T1 research network
FFFE New NSFNET T3 research network
Additional routing domain values may be assigned for specific purposes, such as demo and show networks.
Within the current T1 operational and research backbones, the AREA value will be 0000. The ID will be two octets of zero, followed by the four octet primary DoD IP address.
The NSEL on all machines will be zero.
The AREA and ID values for the T3 networks are for further study.
Typically, only a single NSAP address will be assigned to each machine. In cases where another implementation demands, it is possible to assign an additional address to a machine for announcement via ES-IS to other routing domains.
Each NSFNET backbone routing domain will be run as a set of level 2 IS-IS routers.
Example: PSP-17-10, which connects the NSFNET backbone to the Merit regional network, would be assigned the following address:
47 0005 80 FFFF00 0000 0001 0000 0000818C110A 00
AFI IDI DFI AAI RES RD AREA ID NSEL
The addressing plan presented here should not constrain the future administration of NSAP addresses in the Internet. There are a number of available options, with both technical and administrative facets.
The primary technical issue is one of mapping the address structure onto the Internet topology. It is well understood that a good mapping between address structure and routing topology will result in reduce overhead in routing information. Mapping the three-level structure of the NSFNET segment of the Internet onto the GOSIP address structure can be done in a number of ways:
- AAI = NSFNET, RD = regional. This implies that campuses will be part of the regional’s routing domain, which means that campuses will be unable to do policy-based interdomain routing.
- AAI = NSFNET, RD = campus. This closely parallels the situation with IP net numbers today, and suffers the same problems of scaling (namely a large flat address space).
- AAI = NSFNET, RES = regional, RD = campus. This approach carries the political and technical liabilities, if any, of using the REServed field. Note that anyone given an AAI can do basically anything they like with the remainder of the address, so there is no “legal” problem.
- AAI = NSFNET, RD = regional/campus. This approach would split the RD into one octet subfields.
- AAI = regional, RD = campus. This approach carries the penalty of having to convey more information at the highest levels of the routing heirarchy (tens of AAIs rather than one) but may prove more palatable politically as it appears to give the regionals more autonomy. It also allows regionals to connect to multiple backbones without having to use multiple addresses or suffer routing inefficiencies. This approach is advocated in the Guidelines for OSI NSAP Allocation in the Internet (by Richard Colella of NIST and Ella Gardner of Mitre).
Intertwined with the technical issues of address structure are the administrative details.
In the first four approaches listed above, the address space is “owned” and administered by NSFNET. This would give NSFNET the option of either administering addresses down to the campus level, or simply delegating address space to the regional networks (in all but case 2). Delegating space to the regionals reduces NSFNET’s administrative responsibilities to a negligible level; administration to the campus level may provide better coordinated and planned addressing at the cost of increased administrative overhead.
In the final approach listed, either AAIs could be directly assigned and administered to regional networks, or NSFNET could be assigned a block of AAIs, which it could administer along regional network boundaries. NSFNET could conceivably later delegate the responsibility for some of these AAIs to regionals that were able and willing to take over the administration. It appears that NIST and GSA are willing to assign a block of AAIs to NSFNET to administer in this way. Whether or not NSFNET is willing to take on large-scale address administration depends on administrative and funding issues which are as yet unresolved.
The political ramifications of addressing authority remain to be seen. Regionals may be more comfortable with their own address space than to have address space subordinate to NSFNET, even though there may be little technical difference. Campuses have little choice than to have address space taken from regionals if routing is going to work in the long run.
Near-term Administration
NSFNET will provide NSAP address space from its initial AAI assignment, on a temporary basis, to those organizations wishing to participate in CLNP pilot experiments that do not have another source of address space. This address space will be retired upon such time as a formal address assignment mechanism is in place.
APPENDIX D — IP ADDRESS SPACE
- Short-term hacks of the existing address format
- Create more Class B’s by “borrowing” from Class A. (Method proposed on IETF mailing list.)
- Create more Class B’s by “borrowing” from Class C.
- IP option for more bits of extended addressing
- Use new “Class E” format as pointer to more bits of extended address in IP option area. (Method proposed in IETF mailing list. Advantage is no option parsing required.)
[In c. and d., there are various ways to treat the “extra” bits. Could consider the additional bits as extention to net number, or could consider the extra bits as another layer of hierarchy (eg, include AS# in option of each packet and use it like a telephone area code)]
- New address format in current IP packet format
- IP option for new address format
- Use new “Class E” format as pointer to new format address in IP option area. (Again, advantage is no option parsing required.)
- New address format in completely new packet format.
- IP Version 6 (ie, open up to other IP improvements, too)
- Replace IP with CLNP (but retain rest of stack)
[Note: in 2. or 3. could use any new addressing scheme eg, Tsuchiya’s Kampai addressing.]
- Punt the whole issue. Let IP run out of steam, and use this as motivation to move to complete OSI stack. We can call this the “DECnet approach”.
- Combine this issue with inter-domain routing issue. Approach makes sense for IDPR.
From pgross@NRI.Reston.VA.US Fri Oct 5 02:05:42 1990
Below are some proposed methods for achieving more Internet addresses.
Some of the schemes below are short-term hacks. Other schemes have fundamental implications on the Internet architecture. Some are related to, or are variations of, others. Most require changes to both hosts and routers. The advantages and drawbacks of these schemes are good topics for discussion.
Noel Chiappa has prepared a more elaborate piece discussing the addressing issue in more detail, and how it might be approached in relation to the inter-domain routing problem. His main point is that getting more address space is only one side of the problem. We don’t yet know how to route in the number space we have.