Next Generation and OSI BOF (NOSI) Reported by Dan Harrington/DEC and Brian Carpenter/CERN The NOSI BOF met on Wednesday, 5 April, at the 32nd IETF. The session was chaired by Brian Carpenter. This was the second (and therefore final) NOSI BOF and was attended by about 30 people. Agenda o Bash agenda o SC6 status report o Review draft-carpenter-ipv6-osi-00.txt Agenda Discussion It was asked whether NOSI was the correct forum to discuss the IETF/ITU relationship. Brian Carpenter responded that this was an issue for the IESG or the IAB. SC6 Status -- Jack Houldsworth SC6 has issued three documents: o Text for CD ballot, in which ISO recognizes RFC 1006 as a Standard. o ICD request on behalf of IANA, to fulfill needs of the current Carpenter draft. o A draft statement of direction concerning CLNP, IPv6 and related matters (e.g., regarding OSI applications over RFC 1006), and future work with the IETF (e.g., possible TCPng, Fast Packet support for satellites). Jack stated that SC6 is ``over the nervousness'' regarding Internet cooperation. It was noted that with Stev Knowles leaving the IESG, the formal liaison from IESG to SC6 has to be redefined. Issues On The Current Draft The draft ``Mechanisms for OSI NSAPs, CLNP and TP over IPv6'' (draft-carpenter-ipv6-osi-00.txt) was reviewed to clear out the issues identified in the text and since it was published. (The issues are renumbered here compared to the draft). Editorially, the wording of certain sections (e.g., option headers) must be aligned with base IPv6 specifications. An impromptu overview of mechanisms described in the draft was given (for the benefit of a Senior Member of the IETF who had not read it :-). o Slice and dice (restricted NSAPs) o Chopped (truncated NSAPs) o Extension header (for full NSAPs) o CLNP next header o TP4 over IPv6 o IPv6 address as NSAP (with ICD prefix) Ross Callon queried the lack of policy statements, and was reminded that this is a mechanism specification (just like the NGTRANS draft). Steve Deering asked about possible problem scope, typical usage model, etc. These questions were addressed in the first NOSI BOF (see the San Jose minutes) but probably some more rationale is needed in the text. Issue #1: NSAPs in source routes? No particular problem seen here for restricted NSAPs that behave just like normal addresses. Full NSAPs will not work. Issue #2: Multi-homed ES? Add health warning regarding differences in addressing models (per system vs. per interface). Issue #3: Discovery and address configuration with NSAP-based addresses? What makes sense? Restricted seem ok, Truncated not? However, must remain TBD until discovery and address configuration are done. Issue #4: Total Length in NSAP Extension Header required? Logically, not required but elegant to include it. However, if included, all nodes should apply a consistency check to the three different lengths. Be specific in language regarding padding, i.e., zero to maximum 7 octets to bring to 64-bit boundary. This started a discussion whether an extension header or an IPv6 option is the best choice for carrying full NSAPs. It was stated to be a largely aesthetic issue, but Steve Deering suggested an extension header could be more efficient (less intermediate processing). [Note added after the meeting -- A strong argument surfaced in favor changing to a destination option: in the case of an extension header, all IPv6 systems must be able to parse it, even if they have no knowledge or use of NSAPs. In the case of a destination option, intermediate systems need no knowledge of the option in order for it to traverse the network.] Issue #5: Relationship/Location with regard to Authentication Header? Short discussion regarding ordering of headers. Put it after Fragmentation Header. Authentication Header may float a bit in practise. Issue #6: Truncated NSAPs, what are they good for? Dan Harrington explained the general concept, potential use in tunnelling. Steve Deering observed that it is safe to simply truncate NSAP at 15 octets, as low-order bits will not affect routing. Issue #7: Does Truncated NSAP make sense as Pack/Anycast address? (Note that the draft uses the obsolete term ``pack.'') Yes, as destination address, but never as source address. Language in draft to specify a valid unicast address as source. Issue #8: TCP pseudo-header checksum -- include NSAPs from extension header? Keith Sklower pointed out that this was necessary, and was specified in TUBA documents -- to be added as an appendix. Issue #9: Tunnelling case: CLNP PDUs should be segmented (as per CLNP protocol) if size > IPv6 path MTU. Rationale: If Anycast destination is a set of CLNP/IPv6 border routers, packets may not be sent via same path, hence IPv6 fragmentation may not be possible. CLNP segmentation can allow reassembly at final destination. Issue #10: Scott Bradner queried the restriction on recursive embedding (NSAP may not contain IPv6 address in NSAP format). He asked for more context in the text and a clear statement of how to ``make'' an IPv6 address in this case. Ross Callon noted that recursion might cause routing table explosion. Brian Carpenter noted that recursive addressing is mighty like recursive encapsulation (see RFC 1326, P. Tsuchiya, ``Mutual Encapsulation Considered Dangerous''). Note that in this case, an IPv6 address is formed from an NSAP by removing the AFI and ICD from the left, not by removing bits at the right. Rules are relatively clear -- constants must be clearly stated in the specification (e.g., AFI/ICD, IPv6 prefix for NSAPs, etc.) Issue #11: How many drafts/RFCs to come out of this BOF? Eric Fleischmann: ES addressing can be stand-alone. Extension header makes him nervous. There was some general discussion regarding usefulness of Extension header. It creates multiple classes of IPv6 nodes (do not understand 20-byte addresses, understand them but do not have them, understand them and have them). Alan Lloyd repeated some of the basic arguments from the San Jose BOF why multiple different system types want to share a common network and addressing scheme. Ross Callon mentioned the pure dual stack alternative. There was a request to detail an explanation of what implications exist up and down the protocol stack (API, DNS, etc.) if Ext. header used. Is this really required? There does seem to be some market demand (from the SC6 community), and this elective mechanism may be a selling point. To be resolved off-line. Proposed drafts to come out of all this: Mapping -- Restricted and Truncated (1 or 2 documents?), CLNP Tunnelling, and OSI Transport over IPv6. Issue #12: OSPF routing broken by truncated NSAPs? Ross Callon noticed during the meeting that since arbitrary NSAPs have no guaranteed internal structure one cannot say a priori whether or not they are routable using OSPF or any other specific IP routing protocol, in the general case. In particular the IP subnet model (one subnet = one wire) is different from the ES-IS model (one area = many wires). This potential show-stopper was left TBD due to lack of time. Issue #13: In which working group(s) should this work be carried forward? IPNGWG? TACIT? Others? This was left TBD with the Area Directors.