 |
 |
 |
InterOp '90, San Jose, CA
FOREWARD
The meeting agenda will be found in Appendix A. The attendees were:
FNC Visitors:
Guests for specific topics:
Scribe:
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.
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.
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].
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.
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.
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.
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.
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.
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.
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."
If we are going to change the IP header format for any rea- son, we should expand the addresses from 32 to 64 bits.
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.
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.
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.
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.
This topic was deferred to a later meeting, for lack of time.
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.
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.
The following meetings are presently planned:
Alternate dates, available for PWG:
Full Meetings:
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.
The IAB held a dinner meeting with visitors from Hungary, Poland, and the USSR:
Deputy Director
Institute of Electronics and Computer Science
Latvian Academy of Sciences, USSR
Dr. Udalov is also the Scientific Secretary (Technical Director) of the Council of Akademnet, the Soviet equivalent of the late ARPANET.
Professor
Technical University of Warsaw
Head of Laboratory
Computer and Automation Institute
Hungarian Academy of Sciences
In addition, Dave Caulkins, Executive Director of GLASNET, attended.
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.
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.
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 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:
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.
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.
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.
[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)]
[Note: in 2. or 3. could use any new addressing scheme eg, Tsuchiya's Kampai addressing.]
|
Index of IAB Meeting Minutes |
|