IPNG Working Group BOF (IPNGWG) Reported by Scott Bradner/Harvard University This BOF allowed a number of folks to give ten minute presentations on issues of concern. Dave Sincoskie Dave is concerned about tunneling (encapsulation). This is a good technique for quick implementation of low usage service. However, this tends to result in difficulty debugging networks (an organization which offers underlying service does not know about higher level service, therefore does not know how to fix it). This implies price and quality of service problems. What does this have to do with addressing? The issue with addressing is: What are the problems that we are trying to solve? If the proposed solution to some addressing/routing issues is to use encapsulation, then we need to understand whether there are problems with this approach. The Internet might become the Global Information Infrastructure---we do not want to do this through a mechanism which we know is broken (e.g., for support of mobility). Peter Ford What do we know how to do: Datagram networking with source/destination addresses; speed matters; longest prefix match; some kind of source routing is likely to be used. Addresses are used in a variety of ways (private networks, local versus global traffic, source routing through mesh of providers, etc.). This implies a need for flexible address support. End system unicast addresses (global and local addresses); routing domain identifiers/addresses; multicast addresses. What we do not know: How big the network will get; what we are actually addressing; the ``shape'' of addresses (internal structure, number of levels); what are we really trying to represent (semantic overload of field). Variable length addresses means add flexibility and extensibility. What is maximum size (16 bytes, 32 bytes, larger)? We need to support cluster addresses (addresses for groups of things) and local addresses. There is a controversy regarding whether 16 bytes is enough. In fact we just do not know whether 16 bytes is enough or not. The cost of flexibility is small. Variable length addressing (with sufficient max) ensures that we will not run out, and also allows smaller addresses, therefore better efficiency. John Wroclawski Two things can happen: We can take over the world, we can be a ``lingua franca'' over other things (he left out the third possibility, IPng could fail). Low cost is important (cost to manufacture a telephone is $10; set-top box is $50). Management of link latency (delay and variance of delay) is important. Real and perceived performance: Has to work well, press has to perceive that it will work well. Efficient datagrams we do well. Efficiency for streams of datagrams not so well. This implies that support for flow labels needs to be required. We need to do something about header compression, and not only on slow links. We do not do management of latency. This is a deficiency. Jumbograms make this worse (bigger MTU has a big effect on this). Matt Mathis Wants explicit support for lightweight (compressed) headers; header compression in stream mode; and Jumbograms in order to make TCP work well at very high speeds (OC12 or 48 over WAN). (Van Jacobsen thinks that jumbograms are broken---avoiding this requires some tweaks to TCP. It was suggested that header compression might not be hop-by-hop. Another suggestion was that addresses not be in every packet). Paul Francis Paul is concerned about addressing issues related to connecting to providers: changing providers, multiple providers, no provider. Basic form of address is: ``interdomain-prefix'' plus ``private part.'' The private part must have a guaranteed space no matter which provider, this needs to be specified. Paul questions whether or not 8 bytes is enough for the private part. Provider-routed versus geographical addresses: If you have provider routed addresses, then the inter-domain prefix indicates the provider. This implies that each provider needs to be internally connected. If you have pure geographic addresses, then the geographic areas have to be connected (implying that multiple providers have to cooperate/``connect''). There are tricky problems related to this connection. Provider-based addresses are nice for providers, and hell for subscribers. Geographic addresses are hell for providers, and nice for subscribers. Provider selection implies that you have to have something in the packet which tells you which provider, which seems to imply provider-based addresses. Geographic addresses forces connectivity between providers in every geographic area. Paul thinks that we should experiment with geographic addresses. Brian Carpenter We need to be able to map other address spaces into the IPng address space. Proposes how to map NSAP addresses into IPng. Point is that we need to do this, and 16 bytes is sufficient to do so. The point of this is to make use of existing addressing plans. ``The applicability statement would be a delicate piece of text.'' Steve Bellovin There is a need for multiple addresses per host. This may be used for multiple services on the same host. Permanent (location-independent) and temporary (location-dependent) addresses. Different addresses for billing (bill to address). An ``ARP-replacement'' should not preclude having a moderately large number of addresses per host. Noel Chiappa Noel presented ``Topologically Sensitive Names for Routing in Very Large Networks; or, Why I like Variable Length Addresses.'' Hierarchy is the only way that we know to allow routing to scale. Hierarchical names are sequences of area ``names.'' In order for routing to scale, the addressing must correspond to the hierarchical topology. In a decentralized net, there will be a variation in tree depth. For quality of service or policies, there may be more layers of hierarchy. Thus, what we are doing is representing an essentially variable length thing in a fixed length field. In order to do this, we need to have a very good crystal ball. However, we just do not have a good enough crystal ball. Summary: Variable length topologically sensitive addresses is the natural state of things. We should think about how to make this work well, and not try to fit things into a fixed length field. Bill Simpson Bill is concerned with requirements for mobility. We spend a lot of time niggling bits and bytes to make the headers smaller because the bandwidth of the mobile links is severely limited. Concerned that mobile node users will perceive performance degradation if headers are too big. Bill used the ``two to the n'' argument (assuming relatively dense packing) implying that we do not really need large addresses. Extra hierarchical levels should be minimized (use where necessary for routing, not when unnecessary). Encapsulation (e.g., for mobility) implies two headers which implies still more concern about header size. We cannot make the slow mobile links faster (international treaties, frequency allocation). Larry Wolf Larry is concerned about address allocation issues: They have found address allocation to be very time consuming and expensive. Do not expect more than 64K hosts per subnet. Propose a fixed address boundary for subnet/host. Larry proposed that we should charge for addresses (if you are willing to pay, then you do not need to explain why you need the addresses).