Next Generation and OSI BOF (NOSI) Reported by Ross Callon/Bay Networks and Brian Carpenter/CERN About 35 people attended this BOF, chaired by Brian Carpenter. In the IPv6 base document, and in discussions in the Toronto IETF, it was suggested that it would be useful to be able to map NSAP addresses into IPv6 addresses. This appears to be related to CLNP to IPv6 transition. However, there is no consensus on whether the IETF needs to do anything in this space (for example, work might be done in ISO instead). We need to understand the requirements first, then consider work items, and where (what group) they should be done. Thus, the agenda for this BOF: o Agree on general OSI to IPv6 conversion requirements o Agree on major network layer scenarios o Identify useful mechanisms and hear from their proponents SC6 (ISO/IEC JTC1/SC6) presumably has an issue, regarding whether to continue work on CLNP. We might want to consider (as individuals) giving some ideas to them. Note that Jack Houldsworth was present in the BOF as ISO liaison. DEC is also planning support for customers using DECNET Phase V (using CLNP) to use DECnet over IP -- we would like to understand from the DEC folks how this is being done. Question from the floor: What is the forum for experimental work on OSI applications over the Internet? Nobody had an answer. Brian Carpenter presented conversion requirements: o R1. Existing CLNP networks want to migrate to TP4 over IPv6 o R2. Existing CLNP network wants to migrate to Internet applications over IPv6 o R3. Planned CLNP net changes plan to instead go to TP4 over IPv6 o R4. Planned CLNP network change their plan to instead to Internet application over IPv6 o R5. TP0/CONS net wants to migrate to TP0 over IPv6 o R6. (Are there others?) It was pointed out that the ``TP4'' and ``TP0'' in above requirements should really say ``OSI applications.'' Customers do not care which transport layer protocol is being used. The API over the transport layer may need to stay the same. It was also pointed out that the above requirements are not mutually exclusive; they just show the range of possibilities. Brian then gave four possible scenarios for the network layer: o Proposal 1: The final goal is a pure IPv6 network with pure IPv6 addresses, with no trace of CLNP nor NSAPs. + Simple end scenario. - CLNP investment lost. (This last point is controversial; some knowledge may be maintained, and the knowledge that is maintained may be the bulk of the retrievable investment.) o Proposal 2: Final goal is an IPv6 network in which some hosts have NSAP addresses. + (?) NSAP addressing plans preserved. (This alleged advantage was vigorously debated, with some folks feeling that there is no significant advantage either way, in that the bulk of the effort can be used even if the exact 20 byte addresses are not). -- Extra complexity in hosts and routers. - Two address plans connected only by IDRP. (It was politely pointed out that this is bogus.) - No CLNP service despite having OSI addresses. o Proposal 3: Final goal is a pure IPv6 network with a pure IPv6 addressing and routing, but NSAP addresses are transported end-to-end as an option. + Preserves NSAP plans as pseudo-EID. + Complexity limited to participating hosts. - Two independent addressing schemes. - Still no CLNP service. o Proposal 4: Tunnel CLNP over IPv6. + No modification to IPv6. + Preserves CLNP investment. - CLNP hosts only see each other. There was no discussion about the viability of scenarios 1 and 4. However, 3 found little support and 2 is controversial (see later discussion on address mapping). Mechanisms: o M0: The Null mechanism: Tell CLNP users to run IPv6. o M1: Develop a CLNP to IPv6 transition plan (``Avoid Brutal User Transition'' ABUT). + Stepwise transition like SIP/TUBA. - Some folks think that this might be expensive. (Not clear what they mean by ``expensive,'' or what is the alternative.) o M2: Squeeze NSAPs into 16 bytes. - Does not appear to explain all of the transition steps that are necessary. o M3: Map IPv6 addresses within the NSAP format. + Useful for stepwise transition. - This also is not complete plan (may be part of M1, for example.) o M4: Carry full NSAPs in IPv6 extension headers. + Preserve rull NSAP space. - Complicates routing (how, details uncertain). - Implementation complexity. o M5: Carry NSAPs as end-to-end option. o M6: Encapsulation of CLNP over IPv6: nextheader=CLNP. (This is easy given current standards and software.) o M7: Update RFC 1006 (TP0 or TP4 over TCP over IP). (Seems to be simple.) o M8: Support TP4 directly over IPv6. (This is easy given current standards and software.) o M9: Map NSAPs to IPv6 addresses via DNS. Ross Callon gave an overview of ABUT (TUBA backwards) which he will summarise for the mailing list. Essentially it is a dual stack transition as proposed for TUBA and IPv4 to IPv6. Jim Bound gave a description of a mechanism for mapping NSAPs into 16 byte IPv6 addresses. o Split CLNP address into a high part and low part o Map the high part and recombine with the low part For details see draft-carpenter-ip6-nsap-map-00.txt. This draft is alleged to cover all known deployed CLNP addressing schemes (ICD and DCC formats with unused and reserved bytes deleted). Proponents of other schemes need to show why this is insufficient. Ross pointed out that the ABUT transition scheme does not require any particular relationship between CLNP and IPv6 addresses. Each organisation can use whatever means it wants (assuming that the addresses are topologically reasonable). It is permitted and reasonable to use the Jim/Brian address mapping, but ABUT does not require that all organisations coordinate their means of mapping NSAPs into IPv6 addresses. Jack Houldsworth gave an overview of NSAPs. He pointed out the flexibility of NSAPs (for example, the ability to encode X.121, F.69, E.163 and E.164, etc). One question came up regarding which of these formats are actually used? Clearly E.164, DCC, and ICD are being used. Perhaps the biggest difference between NSAPs and IPv6 addresses is that NSAPs explicitly allows embedding of many different other address families, whereas IPv6 addresses are expected to be assigned for IPv6 in a topological/well packed manner. Jack also proposed a scheme where the IPv6 address field would be the ``top'' of an NSAP, with the leftover part in an IPv6 option. For details see draft-houldsworth-ip6-nsap-use-00.txt. A transition mechanism for ABUT was proposed by Ross Callon here. If what comes back from DNS is an IPv6-type NSAP address, then use simple IPv6. Otherwise, do another DNS lookup to map the ``real'' NSAP into IPv6, and then encapsulate the full NSAP address. We could first migrate the CLNP world towards trivially IPv6-mappable addresses. Alan Lloyd discussed options for sorting out addressing. His goals are: To provide ``harmonisation'' between ISO NSAPs and IPv6 addresses; to permit ISO to administer some of the IP address blocks; to provide a network design approach that enables address convergence to IPv6. He stated a requirement: to have compatible address forms for NSAPs and IPv6. IPv6 in NSAPS are easy. For NSAPs in IPv6, propose to assign first bytes of IPv6 addresses to be compatible with some NSAP AFIs. These need to use assigned NSAPs which fit into 16 bytes. This thereby allows ``bi-lingual'' addresses. For details see draft-lloyd-ip6-iso-itu-reg-00.txt. The view that IPv6 addresses and NSAP addresses (such as those for ATM) should be harmonised, i.e. part of the same global address space, was strongly defended by Alan Lloyd. [However, it seems to be at odds with the architectural view of IP as ``one protocol to bind them all'' with an over-riding address space. This architectural issue was not clearly identified during the BOF, but has since been raised on the mailing list. Further debate on this is required.] Multiple people were concerned about the implications of splitting the NSAP address between two parts of the header -- the first ``n'' bits in the IPv6 address, and the rest in an extension. Keith Sklower was concerned about embedding the NSAP length as the high order part of the address, since this causes an explosion in the number of routing entries in forwarding tables. Jim Bound and Ross Callon expressed support for the notion of providing a graceful migration from CLNP to IPv6, but also expressed strong concern with specific technical aspects of Alan's proposal, stating that the proposal had to work well and be implementable, reasonable efficient, and manageable. Dan Harrington, DEC presented an alternative proposal. The ``top'' of an NSAP (actually the part useful for routing) is in the IPv6 address, and the entire NSAP is carried in a header extension. This is similar to the Houldsworth/Lloyd proposals but perhaps slightly cleaner. It appears that all of these proposals are compatible with the ABUT transition scheme, in which either CLNP or IPv6 is used end to end for any particular datagram. Work items: o Description of the ABUT plan (Ross Callon) o Address mapping needs to be worked on (all, combined proposal needed) o Tunneling (simple, but volunteer needed) o TP4 over IPv6 (new work, volunteer needed) o RFC 1006+ (fairly simple, Scott Bradner was heard to volunteer) Action items: proposers will write up their own proposals if not done. The group expects to meet again in Danvers. The objective would be to decide whether ABUT and/or a combined address mapping proposal should be followed up (working group chair and activists needed for that). The architectural issue about address space harmonisation also needs to be resolved. To subscribe to the NOSI mailing list, use majordomo@sunroof.eng.sun.com, and write subscribe nosi in the text. At present this is not an archived list.