To: sipp@sunroof.eng.sun.com Cc: francis@slab.ntt.jp, deering@parc.xerox.com Subject: IPng Directorate meeting in Chicago; possible SIPP changes Date: Tue, 31 May 1994 11:21:31 -0700 From: Steve Deering Message-Id: <94May31.112133pdt.12171@skylark.parc.xerox.com> To the SIPP WG: As most of you know, the IPng Directorate met on May 19 & 20 in Chicago. We (Paul and Steve) are both on the Directorate, and were present. The Area Directors also invited experts on specific aspects of the various proposals to attend; the invited SIPP experts were Ran Atkinson (security), Bob Gilligan (transition, API), Erik Nordmark (transition, implementation), and Sue Thomson (auto-configuration). Bob Hinden was also invited, but could not attend. The purpose of this message is to inform the SIPP working group of what happened in the meeting (separate minutes will be generated, but we wanted to give you our perspective), and to get feedback from the group. Most of the Directorate members had performed a detailed review of all or most of the IPng documents, as preparation for the meeting. The first item on the agenda was to ask everyone present to briefly state their most serious concerns about each of the IPng candidates. The recurring (and unsurprising) concerns about SIPP were: (1) complexity/manageability/feasibility of IPAE, and (2) adequacy/correctness/limitations of SIPP's addressing and routing model, especially the use of loose source routing to accomplish "extended addressing". Discussion of the first concern was postponed to near the end of the meeting, under the agenda topic "Transition". That discussion was not conclusive, but a lot of mutual education occurred. IPAE clearly needs more work in clarity of description, modularity of functions (e.g., between encapsulation, translation, and address mapping), and, perhaps, design details (e.g., C-bit vs. C-prefix), before it will be acceptable to the Directorate or the community. Discussion of the second concern took up most of the meeting, under the general agenda topic of "Addressing and Routing". Paul gave a lengthy tutorial on how SIPP extended addressing and routing works, clearing up some misconceptions. However, many people remained nervous about one or more aspects of SIPP extended addressing: o A number of people were justifiably uncomfortable with the fact that we have no experience with best match routing where the complete address is not parsed by every router. With the SIPP extended addressing mechanism, routers often make a routing decision by looking only at the lower-order part of the extended address. This clearly requires careful configuration, and could have strange failure modes as a result of misconfiguration. (Other uses of the SIPP Routing Header, such as provider selection through cluster addresses, were still considered important and valuable to retain.) o At the topological boundaries corresponding to the boundaries between 64-bit address components, SIPP extended addressing sometimes requires either that the routers maintain multiple, disjoint routing tables or that they be limited in their permitted interconnection topology. Some people were not happy with either of those options. o When using extended addressing, the current SIPP specs require that the low-order 64-bit element of an extended address be globally unique, for use as an "identifier" by higher-layer protocols. We had proposed to use SIPP local-use addresses, auto-configured from IEEE 802 addresses where possible, as those low-order Identifying Addresses. However, people were nervous about relying on IEEE 802 addresses to be globally unique. Among the problems here are 1) that there seem to be a lot of duplicate IEEE 802 addresses assigned, and 2) that the IEEE 802 address space itself may expire, given that they are allocated very sparsely, and that there is no mechanism in place to reallocate unused ones. o The lack of syntactic distinction between those address parts being used for extended addressing and those being used for source routing raised concerns about the security of reversing the Route Header to generate replies. (This was discussed thoroughly on the SIPP mailing list a few weeks ago.) Based on this discussion, we concluded that use of the SIPP Route Header to accomplish extended addressing was unacceptable to the Directorate. At a private meeting of the SIPP "delegation", Steve proposed to address these concerns by changing SIPP as follows: - Change address size from 8 bytes to 16 bytes (fixed-length). - Specify optional use of serverless autoconfiguration of the 16-byte address by using IEEE 802 address as the low-order ("node ID") part. - For higher-layer protocols that use internet-layer addresses as part of connection identifiers (e.g., TCP), require that they use the entire 16-byte addresses. - Do *not* use Route Header for extended addressing. Even though Steve continues to contend that 8-byte addresses are more than big enough, and therefore that extended addressing would never have to be used anyway, he recommended these changes for the following reasons: - It allows serverless autoconfiguration of global addresses, using IEEE 802 addresses, which is very important to some communities. - It makes SIPP much more attractive as a possible IPXng, as well as an IPng. - It should stop the incessant complaining about SIPP addresses being too small. 16 bytes will hold all of the information in a 20-byte NSAPA (after you drop the trailing SEL byte, compress the small number of values that consume the first two or three bytes down to one byte or less, and use CIDR-like address allocation, rather than fixed internal field boundaries). The rest of the SIPP delegation supported this proposal (some reluctantly), and we presented it to the full meeting. While some Directorate members and invited experts felt that the new SIPP proposal was an acceptable approach, many people continued to argue for variable-length addresses--specifically addresses that can grow in units of 8-byte chunks. Thus, an address could be 8 bytes, 16 bytes, 24 bytes, and so on. A small group of us (SIPPers and non-SIPPers) held a late evening discussion on a number of aspects of how variable-length addressing would work, including what the upper bound would be (one participant argued for an upper bound of 56 bytes), and how it would be encoded in the packet. When you go to variable-length addresses, it is much more expensive to do source routing in the IPv4 style (i.e., by swapping in a new destination address on each leg of the path), so we looked at alternatives, in particular, a scheme in which the main header contains the full address sequence (source address, intermediate 1, intermediate 2, ..., destination), with a pointer to the "currently active" address in the fixed part of the header. On Friday morning, Steve presented a summary of the evening discussion to the full meeting, with the disclaimer that this was not a SIPP proposal and that he was only summarizing a discussion, not presenting his own position. The Area Directors then polled all attendees, and most people said that they were pleased with the general direction things were going and they could see the possibility for a consensus agreement by July. However, there were many specifics still to be nailed down, e.g., fixed, 16-byte addresses vs. variable length, what max length if variable, detailed packet layout, etc. The small "evening discussion group" then spent a couple hours exploring packet layout alternatives, but did not reach any resolution. We agreed to take these discussions back to our working groups to get broader input. -------------- After Thoughts (since the meeting) Early in the discussions, both of us (Paul and Steve) thought that variable- length addressing might be acceptable, particularly because it would allow the use of *shorter* (8-byte) addresses for those that do not wish to use IEEE-802-derived addresses and for cluster addresses used in the Route Header. During discussions on how it would work, however, we both became increasingly uncomfortable with it. At a high level, what we feel is a good approach is to make all SIPP addresses 16 bytes in length, possibly with some scheme to truncate cluster addresses used in the Route Header. For high performance forwarding of source-routed packets and richer source-routing semantics, we should examine alternative ways of encoding the Route Header, preferably with input from the SDRP WG. Regarding variable-length versus fixed-length addresses, we want to make a number of statements. 1. 16-bytes is enough. There should be no need to ever increase the address size beyond 16 bytes. Indeed, 16 bytes of SIPP address has roughly the same amount of address space as a 20-byte NSAP address. If you take away the low-order selector byte of the NSAP address, and the high-order bytes wasted to encode various allocation authorities, the two addresses are roughly the same size. Nobody has complained that the NSAP address is not big enough. 2. There is no such thing as a variable-length address. "Variable- length" addresses immediately grow to their maximum size. This is certainly true of the NSAP address, where most encodings are the full 20 bytes. Thus, I think that no matter what bound we put on a variable-length address, the maximum size will be used. It's just human nature. Thus, we may as well pick a fixed size and take advantage of the resulting simplicity. There was discussion during the meeting of having a variable-length address in the packet encoding, but somehow "profiling" a 16-byte address for initial use. The argument was that this would make it easier to grow the address when it became necessary. We think, however, that if you effectively limited the address to 16 bytes, then so much of the world's equipment would expect it that it would be just as hard to effectively change the address size as it would be with no variable- length address packet encoding. 3. A 16-byte SIPP address does not prevent encoding existing NSAP addresses in the SIPP address. Because so few of the IDPs have been actually assigned, they can be re-encoded as a small number of values at the high end of the SIPP address. Thus, we can have convergence with CLNP without having unnecessarily large addresses. 4. Variable-length addresses cost more than fixed-length addresses. They cost more because the complicate processing, and because, as mentioned above, they tend to grow to their maximum length and therefore create longer-than-necessary packets. If they aren't needed, why should we allow them? 5. Variable-length addresses promote bad address assignment practices. People who are not knowledgable about what should go in an address tend to put organizational information in addresses rather than pure topology information. This appears on the surface to make address assignment easier--people can carve out and identify their space. I think, however, that putting organizational information in addresses is bad practice because it creates more opportunities for gratuitous changes in the address. That is, addresses must change not only when the topology changes, but when the organization changes. We should discourage such practice. Note that not putting organizational information in the address does not prevent the address from being assigned along an organizational hierarchy. IP addresses under CIDR are an example of this. The top level of the CIDR address in the hierarchy is provider. This, however, doesn't mean that CIDR addresses are assigned directly to providers. Rather, they go through one or more assignment authorities first (NICs). It is irrelvant what NIC a CIDR address came from to routing, so this kind of gratuitous information does not appear in the IP address. Indeed, one could argue that putting organizational information in an address creates more problems than it solves, because then organizations start fighting over address space. If there is organizational information in an address, then organizations naturally want to have big address spaces reserved for themselves. If there is no such information in the address, then organizations can be assigned smaller blocks because there is less ego associated with the blocks (additional blocks can be given to an organization if it needs them later). Organizations' address sizes are, as it were, hidden behind the pants. Nobody cares. Organizational address assignments should be discouraged, first by not having organizational information at the top of the address hierarchy (and thus not setting a bad example), and second by giving clear guidance to private network operators on how to assign addresses. -------------- We would appreciate your comments on any or all of the above. Especially, we would like your opinion on: - leaving SIPP addresses as they are (8 bytes long), - changing SIPP addresses to be 16 bytes long, or - changing SIPP addresses to be variable length (multiples of 8 bytes) up to some maximum length (please specify). Paul and Steve