RFC1006bis/ISO TP over IPv6 BOF (RFC1006) Reported by Robert Watson/DEC The RFC1006 BOF met on Wednesday, 19 July, at the 33rd IETF. The session was chaired by Keith Sklower/Berkeley. This BOF was the first on this subject and was attended by about 26 people. This session was originally intended to run on the MBONE but due to room change this was not possible. The mailing list for continuing discussion is tosi@lkg.dec.com. To join the list, send a request to tosi-request@lkg.dec.com. Agenda o Agenda bash o Purpose of this BOF o Draft reviews - Carpenter proposal: CLNP and TP4 over IPv6 - Pouffary proposal: TP2/TCP o Discussions - Other extensions/corrections to RFC 1006 o Becoming a working group - Milestones - Charter Purpose of this BOF This BOF is the result of input from the Transport Area Director on the need to revise RFC 1006 for use over IPv6. Some minor changes have been identified (e.g., removal of reference to IPv4) and so, whilst the covers are off, are other changes needed? Agenda Discussion During the agenda discussion it was clear that there were two needs which would be covered. The first would be to provide a solution for running ISO Transports, especially ISO TP4 over IPv6, and the second related to preserving and improving RFC 1006 for use over IPv6 and IPv4. There is an installed base for RFC 1006. Draft Reviews The draft for OSI CLNP and TP over IPv6 (draft-carpenter-IPv6-osi-01.txt) was reviewed. It was noted that despite the name of the draft, the text is very close to that provided by Dave Katz/Cisco and Stephen Thomas/AT&T Tridom. This draft describes two mechanisms, CLNP encapsulated in IPv6 which is a CLNP tunnel over the IPv6 cloud, and ISO Transport Protocols over IPv6. This second mechanism was described in the session as TP4 over IPv6. A short summary of the two mechanisms described in the draft was given to ensure that discussion of this and the following draft would take account of the different approaches being described. o CLNP in IPv6 The CLNP tunnel mechanism provides a virtual point-to-point link over IPv6 where the IPv6 payload is simply a CLNP datagram (which might actually be data or ES-IS, IDRP, etc.). There is no restriction on the OSI addressing scheme, (it does not have to be derived from US Gosip, etc.), no multicast simulation, and no RFC 1070-like shim. With this scheme it would not be possible to use IPv6 fragmentation especially if the destination is an anycast, as fragments would not necessarily arrive all at the same host. It is necessary to play safe and use CLNP segmentation. o TP4 over IPv6 The TP4 over IPv6 mechanism simply provides an ISO Transport TPDU over an IPv6 network, simulating the ISO Connectionless Network Service. There are some Path MTU discovery considerations. ISO TP must take advice from the lower layers when establishing a suitable PDU size. If any ``ICMP too big'' messages are received during the life of the connection, this information must be used by ISO Transport to adjust the PDU size for new PDUs. Existing PDUs cannot be re-packetized and therefore IPv6 fragmentation must be used. It was noted that, unlike IPv4, there is no assurance in IPv6 to purge stale packets, therefore the ISO Transport protocols should handle PDU lifetime. The draft, ``ISO Transport Class 2 Non-Use of Explicit Flow Control over TCP RFC 1006 Extension'' (draft-pouffary-tcp-01.txt), was presented for the first time. This draft describes the small number of changes which are required to the existing RFC 1006 mechanisms to allow upper-layer protocols like DECnet, which require features not provided in RFC 1006, to run over TCP. The missing features are independent of normal and interrupt/expedited data channels and Synchronous Disconnect mechanisms. The goal of the draft is to minimise the number of changes to RFC 1006 and ISO Transport (ISO 8073) protocols, whilst maximising performance and protecting the installed base of RFC 1006 users. A number of possible solutions were described and rejected as they did not meet these goals. The proposed solution, which suggests use of ISO TP2 with no flow control (as opposed to ISO TP0 as in RFC 1006), does not require any new TPDU formats, only changes in the rules for the use of ISO TP2. The proposal is not specific to IPv4 or IPv6, as it simply uses TCP and if TCP also runs over IPv6, then this mechanism will work on both. This mechanism makes use of splitting and recombining, in ISO TP2 (not TCP) to provide two channels between the same user thus providing a mechanism to deliver interrupt or expedited data to the remote user even when the primary channel is blocked by flow control. Note: This mechanism is not being used for sharing a single TCP connection between multiple Transport connections. It was suggested that a diagram would help understand the difference and the mechanism being proposed here. When the protocol was described the presenter noted that the current draft does not fully describe the Synchronous Disconnect mechanism. Optional data in the DR/DC is used to ensure data is delivered to the user before the underlying connection is destroyed. This will be added to the draft. There are two implementations of this proposal, one on OpenVMS and one on UNIX. Discussion General Comments It was noted that not all the mechanisms above may be required. There was a desire to reduce the number of solutions, and whilst there maybe a preference for one mechanism or another, choosing just one might be better than having too many. From the perspective of application writers, minimizing changes to RFC 1006 is important. Discussion on CLNP tunneling through IPv6 Concern was expressed that there was a statement which said ``thou shall not feed information from ICMP messages back into the CLNP world.'' For example, the information contained in an ``ICMP too big'' message should be used in the CLNP world. The current wording says that no attempted is made to feedback ICMP data to the Error PDU in CLNP. At least this does not say ``thou shall not.'' Whilst the user of the CLNP tunnel can remain ignorant of the conditions outside the tunnel, the tunnel end points should use information such as ICMP messages to define the conditions at each end of the tunnel in the same way as they would for a simply physical connection (i.e., MTU size). Discussion on TP4 over IPv6 What is the purpose of TP4 over IPv6? What problem is it solving? It was noted that RFC 1240 exists and describes CLTS over UDP. If we imagine a CLNP to IPv6 exchange, then TP4 over IPv6 would be needed. It was noted that it should not be that complex to implement. There is an OSI implementation in the Berkeley UNIX kernel where TP4 is already on IPv4 and CLNS and CONS, so it should not be that hard to add support for IPv6. Whilst this is not well-used code, it would be a worthy experiment to try this. Is this a real difference between the behaviour of IPv4 and IPv6 with respect to the TTL? Do routers really hold onto packets for long enough to cause problems. What do CLNS routers do? IP routers treat TTL as a hop count. Discussion on RFC 1006 Extension There was concern that the splitting and recombining would be difficult to implement on UNIX due to the mechanisms used to handle incoming connections. It was noted that there is already a UNIX implementation and that there were solutions to the problems noted. It was noted that the ISO standard requires that expedited data be delivered no later than the next normal packet transmitted. A problem with the current proposal is that if expedited data is sent on the second TCP channel, it might in some circumstances be subject to delays which allowed subsequent data on the normal channel to overtake it. A solution for this was proposed, namely to transmit the same expedited/interrupt data on both the normal and secondary channel. This leads to the need to identify expedited data (sequence numbers) which is not normal in ED TPDU when using ISO TP2 with no flow control. The suggestion and its consequences were noted. Why not just use TP4? If TP4 was run over TCP, it would impact performance (flow control over flow control) and would require much new code to be written by anyone who has only so far implemented TP0. The use of TP2 with no flow control ensures no conflict between the TCP and OSI TP flow-control mechanisms. It also minimizes the new code that would have to be written by existing RFC 1006 implementors who want to use these extensions. It was noted that this proposal recommends use of a separate TCP port number. One reason for this is to protect the existing installed base of RFC 1006, in particular, the case where an ISO TP0 implementation has failed to correctly handle class negotiation. Whilst all TP implementations should be able to handle class negotiation, it is known that some cannot. The goal is to protect the existing RFC 1006 installed based. Supporters of the existing RFC 1006 commented that this was obviously sensible, but saw no reason why this extension and any revised version of RFC 1006 should not share a port in the future. It was noted that a ISO Transport connection set-up includes a T-selector which is used to identify the application stack. Therefore the T-Selector can be used to fan out connections to any number of different application stacks. For clarification, it was noted that the bits on the wire in this extension are the same as defined for the ISO TP TPDU formats, and it is only the rules on use of various ISO TP features which have been changed. In the discussion on use of a secondary TCP channel (through splitting and recombination) for expedited/interrupt data, it was noted that: (i) The secondary channel for expedited data is only used in one direction and created when needed. (ii) An additional channel may be used if expedited data was sent in the other direction. (iii) Use of expedited data was optional, and often not used in both directions. (iv) The normal channel is used for normal data in both directions. A question was asked about why the Urgent Data message type was not used for expedited data transmission. It was noted that there were issues with the use of Urgent Data and that it was generally discouraged. The Transport Area Director commented that RFC 1122 concluded that Urgent Data should be avoided. General Closing Comments Does the ISO community want to take over the TP4 over IPv6 work? The representative from ITU was asked to take the technical description of what is being proposed back to SC6, and ensure that there is active participation from ITU and ISO in this work area. Do we need RFC 1006bis plus this extension? Do we need it right now for IPv4? It was felt that we need it because a number of small problems exist with RFC 1006 and some are solved by the Pouffary proposal. Therefore this is a good opportunity to make a new proposal. It was noted that some vendors need the TP2 extensions now. Discussions on Process The Transport Area Director asked whether the drafts discussed here were ready to go to Proposed Standard? Comments and a decision on making a new working group on this topic would be provisional on this decision. The transports are being pulled vertically by the applications and the work requested of RFC 1006bis is aimed at trying to help a number of applications to run over TCP and IPv6. It was noted that the Pouffary proposal had first been submitted as a draft and that the author was asked to delay this until the work could be considered as part of the RFC 1006bis standardization process. Should a working group be formed? The Transport Area Director will have a second BOF in Dallas before deciding if another working group would be formed and if it is fine to have multiple standard documents defined by the work of this group. The TP4 over IPv6 and RFC 1006bis + Pouffary proposals address the two traditional worlds in OSI, which use connection-oriented and connectionless network services. So based on this, it is logical to have two solutions for these worlds in the longer term. The CLNP over IPv6 proposal specifically addresses transition issues and is therefore separate and needed during transition to IPv6. The BOF decided to continue working on these three topics on mailing lists, and to reach a consensus by Dallas. SC6 was encouraged to participate, especially with respect to TP4 over IPv6. Actions Merger of RFC 1006bis and Pouffary The advocates of RFC 1006bis and the Pouffary proposal agreed to work on a common document (see below) which should address [ISO TP0 and TP2] running over [TCP] running over [IPv4 and IPv6]. This work should also take into account RFC 1278bis and RFC 1277bis. CLNP in IPv6 Tunneling It was agreed that there was little left to be done on the CLNP tunneling proposal. This would be completed on the nosi@sunroof.eng.sun.com mailing list and pushed for Last Call on the list. This document should include CLNP over IPv4. It is also suggested to include a paragraph on where to use the tunnel. This can be copied from the tunneling draft. There was discussion on whether this should be submitted as an Experimental RFC or a Proposed Standard. It was decided that keeping it Experimental would make it easier if it were decided to hand this work over to ISO/ITU in the future. Chairs Summary The chair proposed to report the following to the Transport Area Director: o There is interest in pursuing TP4 over IPv6. o There is interest in pursuing RFC 1006bis + Pouffary over IPv4/IPv6. o There is a need to complete the CLNP in IPv6 work. o These pieces of work will be progressed as shown below. o The CLNP in IPv6 proposal will be handled on the NOSI mailing list. o The remaining work will be moved to a (new) mailing list (see below). o The group plans to finished this work before Dallas and have one more BOF. o It is not clear if additional work would be needed after Dallas. o This BOF is explicitly encouraging ITU/ISO to participate. The following documents will be worked: (1) Document for: CLNP in IPv6 Mailing list: nosi@sunroof.eng.sun.com Editor: Keith Sklower/Berkeley (2) Document for: TP4 over IPv6 Mailing list: tosi@lkg.dec.com Editor: Keith Sklower/Berkeley (3) Document for: RFC1006bis + Pouffary Extensions (RFC1006quatre) Mailing list: tosi@lkg.dec.com Authors: A. Young/ISODE and Y. Pouffary/DEC