Robert M. Hinden Sun Microsystems, Inc. November 1994 IPng Implementors Meeting Minutes Cambridge, MA, USA 10-12 October 1994 INTRODUCTION This document is the minutes of the IPng Implementors Meeting held at Digital Equipments Corporation's Cambridge Research Laboratory on October 10-12, 1994. The meeting was hosted by Jim Bound of Digital Equipment Corporation. These meeting minutes were created based on notes taken by Frank Solensky, Ross Callon, and Bob Hinden. The implementors meeting discussed a variety of topics. The result of the meeting, as documented in these minutes, is a recommendation for changes and clarifications in the current IPng specifications made to the IPng working group. ATTENDEES Rob Austein / Epilogue Technology Scott Bradner / Harvard Jim Bound / Digital Dave Bridgam / Epilogue Technology Tony Buno / Penril Duan Butler / Network Systems Ross Callon / Bay Networks Ping Chen / Apple Alex Conta / Digital Mike Davis / Penril Steve Deering / Xerox Parc Bob Gilligan / Sun Microsystems Heather Gray / Digital Dimitry Haskin / Bay Networks Marc Hasson / Mentat Bob Hinden / Sun Microsystems Richard Fox / Netcom Dave Katz / Cisco hinden [Page 1] IPng Implementors Meeting Minutes November 1994 Joachim Martillo / Penril Dan McDonald / NRL Julie Myers / Network Systems Erik Nordmark / Sun Microsystems Charlie Perkins / IBM Yakov Rekhter / IBM Bill Simpson / Consultant Frank Solensky / FTP Brad Stone / HP Sue Thomson / Bellcore Bernie Volz / Process Software Warren Wagner / Process Software Justin Walker / Apple hinden [Page 2] IPng Implementors Meeting Minutes November 1994 MONDAY The meeting started with a call for agenda items from the meeting attendees. The following agenda resulted: Addressing Model Cluster Addresses Neighbor Interactions ICMP Issues Auto-Addressing Transition and Testing Prototype Testing and the "6-bone" Domain Name System (DNS) Turning Off IPv4 Text Representation of Addresses Security Mobility MTU Size APIs for IPv6 Packets Greater Than 64K MIBs and Effects on SNMP Header Compression Latency Elimination for "ARP" (or ARP replacement) Next Meetings Addressing Model ---------------- The issue of assigning an IPv6 address per node vs. per interface was discussed. Deering explained a problem that arises with the address- per-node model with respect to originating multicast packets: when using a multicast routing algorithm that delivers multicasts via a per- source tree (such as DVMRP, MOSPF, or PIM Dense), a host must send a copy of a multicast packet on all those interfaces identified by the source address in the packet; on the other hand, when using a multicast routing algorithm that delivers multicast via a single tree or a per- group tree (such as CBT or PIM Sparse), a host must send only one copy of a multicast packet. Thus, correct host behavior depends on the particular multicast routing algorithm in use, which is very undesirable. The address-per-interface model does not have this problem (a host always sends just one copy of a multicast packet). Thus, the group decided to recommend staying with the IPv4 model of per-interface addresses. Multiple addresses can be assigned to an interface. A single link which has been assigned multiple IPv6 subnet numbers would implicitly allow their connected hosts to transmit packets with the subnet prefix of the hinden [Page 3] IPng Implementors Meeting Minutes November 1994 source address to be set to any one of the subnet numbers assigned to the link on which the packet is sent. The addressing architecture document should add that this recommendation does not prevent the following configurations from being supported: o A single address may be assigned to multiple physical interfaces if the implementation treats the multiple physical interfaces as a single aggregate and hides the the details of this aggregation from the Internet layer. This is useful for load-sharing over multiple physical interfaces. Only one (virtual) interface should be visible to IP. o Routers may have unnumbered interfaces (i.e., interfaces with no assigned IPv6 addresses) for point-to-point links, to reduce the number of interfaces that must be assigned unique addresses. Cluster Addresses ----------------- While there is some general agreement that cluster addresses, that is, addresses with unspecified (zero-valued) low-order address parts, might be useful in the support of mobile hosts, policy routing, and, possibly, other functions, there is still uncertainty on how they would be assigned and used. Another question that needs further consideration is how a cluster address might be used as the destination when the source is within the same cluster as opposed to outside. Further, it was noted that cluster destination addresses would become an exception to the rule of limiting the assignment of a specific IPv6 address to a globally unique interface. The group recommends that cluster addresses should be considered "reserved" until a specific proposal for using cluster addresses is developed. Neighbor Interactions --------------------- ARP over ICMP vs UDP: The periodic advertisement messages issued by Router Discovery provides a host the means of resolving the link-level address of a neighboring router, but there still needs to be a way for routers to resolve hosts' link-level addresses, and for hosts to resolve neighboring hosts' addresses when no router is available. hinden [Page 4] IPng Implementors Meeting Minutes November 1994 At the July IETF meeting it was suggested that the problems associated with updating or generalizing ARP for IPv6 outweighed the potential benefits. Some of the reasons cited were: o Many installed implementations ignore fields that would have to change. o ARP packet format doesn't allow for extension (e.g., authentication). o No lifetime field in ARP packets to bound how long information may be retained After an extended discussion trading off the alternatives of updating ARP or providing the ARP functionality over UDP or ICMP, the meeting attendees were approximately equally divided between the three options but no strong opposition to any of them readily apparent. The group's recommendation was that work would continue with Bill Simpson's draft describing ARP functionality over ICMP with Jim Bound and Alex Conta providing off-line feedback on his concerns with the document in its present form. In summary the group agreed that we should retain the current ARP model, but implement it with extensions to ICMP. Host knowledge of prefixes: An IPv6 host will learn the subnet prefixes to be used on its packets from the routing advertisement messages it receives through Router Discovery, then using "longest match" against its address cache. Routers must be able to send these prefixes. Scope of discovery: The group recommended removing the description of service location extensions from the discovery document since much of the same functionality would be provided by DHCP. "System heard" messages, beneficial to mobile and radio IP, are still under consideration: some feel that this should remain a link-layer feature and implemented only where it would be used while others that want the widest possible support for it would prefer to see this within IPv6. hinden [Page 5] IPng Implementors Meeting Minutes November 1994 TUESDAY ICMP Issues ----------- A rather wide variety of ICMP-related issues came up on second day. The major points were: o ICMPv6 would indicate "packet too big" as a separate error message, rather than being included as one of the causes of a "destination unreachable" error. By using a separate ICMP message type, it would eliminate the need for special-case handling of the "packet too big" subtype of Destination Unreachable messages, such as allowing only such messages to be sent in response to multicasts. o The ICMPv6 specification should add that the 16-bit error pointer can in theory point beyond the end of the packet when the error point is beyond what can fit in the 576-byte limit of an ICMP error message. o The use of a wider selection of error codes was discussed as an alternative to using a pointer to an error byte but the general consensus seemed to be with the latter: there wasn't a strong feeling that we'd be able to come up with a sufficiently comprehensive list of error conditions. o ICMP "redirects" are to be left as described in the current IPv6 ICMP specification. Question was raised about fragmentating Multicast datagrams? This would require a "Pkt too big message" to be sent to source. Steve Deering said he thinks MTU discovery should be done on multicast links. Others want to have routers do fragmentation for multicast traffic. Group agreed to allow pkt to big in response to multicast. Routers should not fragment multicast datagrams. Issues was raised about how much payload to send in response to ICMP error messages. Fill up to 576 or all of packet? The group decided to keep the 576 limit. Pointer could point off end, The specification needs to make this very clear. Auto-Addressing --------------- Dave Katz provided an overview to a document he plans to make available in the next week. When the IPv6 host first comes up, it sends out an ICMP request message to a multicast address to learn its address. The hinden [Page 6] IPng Implementors Meeting Minutes November 1994 locally-administered server (possibly a router) could then apply the degree of administrative torque over the IPv6 address assignments that is appropriate for the site; for example, determining if the local host will be allowed to renew its address assignment or if address lifetimes are advisory or mandatory. It could provide a simple mapping of hardware addresses to network address (e.g., like IPX) or use DHCP in a more complex environment -- the main point is that the server hides this level of detail from its hosts/clients. The original proposal used 16-bit timers for address lease times; the group recommended 32-bit timers based on DNS experience. There should also be a reserved value (all 1's) to indicate an assignment time of "infinity". The scope of the multicast request should be limited to an intra-link hop. There are still some issues that need to be dealt within the areas of handling more than one ARP response from the address server, determinism (especially where DNS configurations will also occur) and address lease times (e.g., when an address change occurs, must existing TCP connections be broken?). This may also suggest the addition of a "create" operation for DNS but would open a number of security issues that would have to be dealt with before it could be deployed. Transition and Testing ----------------------- Bob Gilligan lead a discussion on the Simple Internet Transition (SIT) document which included translating routers and IPv4/IPv6 encapsulation and tunneling. Forms of IPv6 Address IPv4-compatible IPv6 address 0:0:0:0:0:FFFF: IPv4-mapped IPv6 address 0:0:0:0:0:0: IPv6-only address Note: there are no plan to map IPv4 multicast into IPv6) Bill Simpson commented that he doesn't like/want translation. Scott Bradner suggested that people will do it and we need to tell them how to do it in a manner that will interoperate. Ross Callon presented the problem with having two address prefixes which are used in translation. When translating from IP to IPv6, the router is supposed to know which address prefix (0:0:0:0:0:0 or 0:0:0:0:0:FFFF) to use, based on the type of end system. However, in practice it is likely to be impractical for the router to know which prefix to use. hinden [Page 7] IPng Implementors Meeting Minutes November 1994 This implies that in some cases the router may use the wrong prefix (particularly use all zeros where the other would be appropriate). He proposed that a single prefix be used in translation. This would require additional code in all hosts. An alternative would be to have IPv6-only routers at administrative boundaries be able to, where necessary, change the prefix used within the IPv6 packet (even when the packet is not being translated). This would require additional complexity in the translating routers. IPv6 Deployment without Routers: This part of the discussion focused on the question of how two dual hosts (capable of exchanging both IPv4 and IPv6 packets) would communicate when the router(s) between them were only capable of forwarding IPv4 packets: some felt encapsulation would encourage a faster transition to IPv6 throughout the net, others felt this was a disadvantage if it became necessary to make changes later on. Bill said he thought that hosts should not perform encapsulation. IPv6 hosts should not be able to communicate with other off-subnet IPv6 hosts until the routing infrastructure between them was upgraded to IPv6. For now the group agreed that the document will be left as-is with further discussion to take place on the mailing list. There was some agreement that the some of the disagreement on the transition mechanisms were based on what the default values of switches which are used to control the mechanisms. The group agreed that it is very important to explicitly documenting the "sending rules" (i.e., what format of packet to send in what circumstances) in the transition mechanisms spec. IPv4 Route Leaking: One of the transition documents needs to describe how routes to networks within a IPv4-dominant area will be announced to routers on the border of or within an IPv6-dominant area. This needs to include plans for an IPv6-only domain that leaks IPv4 routing information as well as the IPv6-only domain that doesn't. Dimitry Haskins of Wellfleet volunteered to write this up. Prototype Testing and the "6-bone" ---------------------------------- Interoperability testing between prototype implementations will start off much in the same way that the "mbone" work started by encapsulating hinden [Page 8] IPng Implementors Meeting Minutes November 1994 IPv6 packets within IPv4 packets and sending them off to known locations that will decapsulate. The resulting topology between these machines will be called the "6-bone" (aka "G-bone" in reference to S.Deering occasionally misreading his handwriting). Bob Hinden offered to coordinate these efforts. Some testing of direct connectivity between prototypes is also planned to occur sometime in March, 1995; around the time of (or as part of) Sun's NFS Connectathon. Domain Name System (DNS) ------------------------ S.Thomson had sent out a draft proposal on DNS revisions shortly before the implementor's meeting. Those who had seen it indicated that it looked good and close to what's needed; it should also include tie-ins to the DNS security and DNS-PEM working group efforts. In order to avoid creating a dependency on DNS server support for AAAA records, early implementations should be able to fall back on using some form of local file support (i.e. /etc/hosts) to provide the name-to- address mapping. Turning Off IPv4 ---------------- No specific date was suggested for turning off IPv4 routing: S.Bradner, the IPng Area Director, suggested that the question of when or if it occur would fall under the domain of the TACIT Working Group. Text Representation of Addresses -------------------------------- The group reviewed the current formats for typing IPv6 address and agreed to keep the current techniques. hinden [Page 9] IPng Implementors Meeting Minutes November 1994 WEDNESDAY Security -------- Scott Bradner talked about security requirements in the IPng Recommendation. Implementation of security is mandatory. Thus an implementation must be capable of doing both authentication and privacy (encryption). It is not mandatory to actually use it, it is only mandatory to implement it. In fact, the authentication header support can be shipped. However, the encryption cannot be. Just stripping the code is not enough. You cannot, for example, just strip the function. The issue behind this is that currently export of most confidentiality mechanisms (e.g. encryption) from many countries (e.g. all of NATO, Australia, Japan, New Zealand, some other countries) requires the exporter to obtain an export license ahead of time. The difficulty in obtaining such licenses varies on a country-by-country basis. Use of confidentiality mechanisms is reportedly licensed in some countries (e.g. France, Russia). The US government has been known to grant such licenses in the past. Export of "authentication without confidentiality" does not appear to be export-controlled or usage- controlled in any country. Scott Bradner suggest sending comments in response to last call if unhappy with security "mandatory" requirements. Ran Atkinson was unable to attend due to illness.. Bob Hinden read out a message sent by Ran. The relevant contents from his message are as follows: "1) Because of the pressure to put out IPv6 specs in December, I plan to take the packet header agreed to at the Toronto IPv6 Implementors Meeting and revise the "IPv6 Encapsulating Security Payload" spec. I will then put that spec out as a revised I-D. I also plan to add more text to the "How to use DES-CBC with IPv6 ESP" appendix to make it more explicit (e.g. regarding DES initialization vectors). 2) Comments on the other drafts are solicited, preferably via email to me with a specific proposed change and a brief explanation of why the change is proposed. Comments to the IPv6 list are also welcome of course. 3) [Controversial] I'd suggest that the _implementation_ of security be mandatory inside the kernel, but that use of the security be largely left up to individual applications (e.g. an app might request some kind of security via a socket option). hinden [Page 10] IPng Implementors Meeting Minutes November 1994 However, I'd suggest that we make (at least) authentication of ICMP redirects, TCP SYNs, and other security-critical control messages mandatory WHENEVER a security association exists for the source/destination pair. If no security association exists, then there won't be any shared keys and so it will not be possible to add security to any packets even though it is supported by the networking implementation. [NB: We will need to reach agreement on which packets are considered "security critical". I consider Bellovin's paper in ACM CCR (cited in my I-Ds) to be required reading before that agreement can be reached.] At least until the Key Mgmt WG specifies an Internet Key Mgmt Protocol (IKMP), creating such security associations is a manual process (i.e. the admin types the security association data in on the console). Hence users who don't wish to use security at all simply never bother to create any such associations. Users who do create those associations will get basic security protections. Users who do create those associations AND either have applications which request/use security or have an operating system which has been configured to secure applications without specific requests will get the security they desire. Once we have a real IKMP, then systems which implement IKMP will automatically get basic security whenever they communicate with other hosts implementing IKMP and get full security whenever they communicate with other hosts implementation IKMP provided that they have apps that request security. I believe that this is a good balance between making security available, using security to protect the network infrastructure, and not making users pay the performance cost per packet when they do not wish to use it. Note that I am proposing requiring that kernels always implement security, just that it won't be used for any packets unless or until security associations exist. This costs only a single (IF Relevant-Security-Association exists) check per packet when no security association exists. This should be discussed on the list in more detail, but the above is my current view. The IPv6 Security Architecture document contains some proposed requirements already and will be revised to add clarity later this month. I urge that everyone read that and comment about it on the ipng mailing list." There is an existing socket interface API document, which does not say anything about security. We would like to add security knobs to this hinden [Page 11] IPng Implementors Meeting Minutes November 1994 API. There is already a GSS API for security. however, this may be overkill for IPv6 (the spec is 200+ pages). What we want is simple hooks for requesting authentication and/or privacy. Mobility -------- There are two proposals (Charlie Perkins and Bill Simpson). Charlie presented what he believes are the advantages of his proposal: He is proposing and end to end options type, to send a "binding", which is roughly: {} The corresponding hosts (hosts which are talking to mobile hosts) can maintain the bindings between the mobile host's address and the "care of address", which is where the mobile host is currently. The goal of this is to make use of the home agent a rarity. In the case that the mobile host is the one initializing communications, it may be possible to avoid use of the home agent at all. Given the ability with IPv6 to auto-pick-up-an-address, the mobile host could obtain a temporary address wherever it moves, and be its own "foreign agent". Packets could be transmitted using either encapsulation or source routing. A stripped down encapsulation may also be used. Suggest that the mobile host send the "here I am" packet to the cluster address corresponding to its original address. Bill Simpson began to make a strong argument over patents / intellectual property. Charlie has a patent (owned by IBM) which is already granted, but Charlie says that his patent does not relate to this stuff. Charlie has informed the chairs of the working group of the patent, the working group informed the area director, who informed the IESG, and believes that IBM will make the patent freely available. Bob Hinden and Ross Callon pointed out cases where companies really need to obtain patents. Thus we should not be "blaming" anyone for getting a patent. Scott Bradner points out the policies for Internet Standards require that the patent holder make the patented technology available in a reasonable and non-discriminatory manner. Thus we need to get a signed letter from IBM making this statement. Bill believes that IP mobility has circumvented the patent, by using a hinden [Page 12] IPng Implementors Meeting Minutes November 1994 tunnel to a foreign agent. This also eliminates encapsulation on the last hop, which is important given that last hops to mobile hosts are sometimes low bandwidth. Bill also thinks that the patent is not valid. This issue is best resolved in this individual case by getting a letter from IBM giving up rights to this patent. In the general case, patent issues are going to continue to be nasty. Bill's approach is similar to the IPv4 method. He does not use an end to end option. He uses a remote redirect instead (to avoid the extra hop via the home agent). The Mobile IP group has spent a lot of time considering many different proposals. It is highly desirable to avoid this same deadlock with IPv6. However, it appears that the mobile IP group is finally reaching conclusion. Scott Bradner asked that the issue be tabled in this meeting due to the conflict over the patent so no resolution was reached. MTU Size -------- Two issues were discussed. 1) The Required MTU that links have to carry, and 2) The minimum overall packet size that host has to be able to reassemble. The group agreed that the minimum reassembly buffer size should be raised to 1500 bytes so as to avoid a number of problems associated with DNS and shorter packets. The minimum MTU remains at 576 bytes. APIs for IPv6 ------------- Alex Conta raised a few issues which could be taken up on the mailing list. We have added a mechanism to allow applications to retrieve and/or send source routes and flow labels. Question was raised about being able to switch flow IDs during a TCP connection? For example, an application may decide that it needs a different quality of service in the middle of a conversation. Thus, we might have a "change flow label" command across an API. The kernel needs to pick flow IDs, in order to assure coordination of flow IDs across multiple applications within a single host. Making APIs for IPv6 identical to the API for ATM was suggested, but did not elicit wide support. hinden [Page 13] IPng Implementors Meeting Minutes November 1994 Effects on routing Protocols: The IESG Routing Area Director should make sure that extension of IP routing protocol for IPv6 are being worked on. Header Sequence Rules: The IPng speciation in effect essentially says "should", and this is the right thing, it should specifically say "SHOULD". What should an implementation do if fields are out of order? The specification does not say anything about this at this time. Reversing Source Routes: What are the host rules? What about when a router generates an ICMP response. Bill Simpson said he doesn't like reversing source routes, that this is not the right approach for mobility, nor for authenticated packets. However, if source routes are used for policy reasons, they should be reversed. One option would be to have two types of source routes, one of which is reversible and one of which is not. With ICMP, there is a concern that the reply might not get back if the source route was required to get the packet through (e.g., to send a packet via a path which for policy reasons will agree to forward the packet). The rough consensus of the group was to include a bit in the source route which provides a hint from the source host thought indicating that the source route should be reversed on resulting ICMP packets. The justification is that the entity which picks the source route knows why it is picking the source route, and therefore should have a better idea whether it needs to be reversed or not. Packets Greater Than 64K ------------------------ One option here is to have a non-linear length field, so that a 16 bit field can be used to indicate packet lengths with one byte granularity for packets up to length 32K, and then (if the high order bit is "1") use a larger granularity for the upper half of the field values. Another option is to have the value "zero" have a special meaning. Thus a length of zero means that there is an end to end option which has the real length. The group decided to stay with the "zero" case approach. There is an issue raised by Bill Simpson regarding the effect that long packets has on error checking, both in terms of the strength (hamming distance) of CRCs, and in the probability that the packet actually get through without an error. Steve Deering pointed out that the people who want this feature will use them over reliable (i.e., retransmitting) hinden [Page 14] IPng Implementors Meeting Minutes November 1994 lower layers which causes these issues to be inapplicable. MIBs and Effects on SNMP ------------------------ We need MIBs and volunteers to do MIBs. Much of this work is updating existing IPv4 MIBs. There is an issue regarding human-comprehensible ways to represent IPv6 addresses. SMI needs to be updated to be able to represent IPv6 addresses. The Network Management AD should be poked about this. Frank Solensky volunteered to do an update of RFC1213. Header Compression ------------------ Bill Simpson has written an Internet Draft. This compresses as much as he could manage. Jon Crowcroft has an alternative which is a delta on Bill's draft, which Bill and/or Jon will forward to the IPng mailing list. Latency Elimination for "ARP" (or ARP replacement) -------------------------------------------------- A proposal was also made by Alex Conta that would cause the first packet sent to an peer with no MAC-layer address resolution in the ARP cache to be sent to a multicast address and encapsulate an option or payload field that, at the same time, presents the ARP request to other hosts and avoiding the additional delay it would take between sending out a separate ARP request and waiting for the reply. Using a TTL set to 1 when the address prefix was unknown was also considered as an alternative; this would have required some definition or configuration of ICMP Time Exceeded suppression. Another option is to multicast the packet instead of first sending an address resolution request. We need to multicast an ARP request anyway, why not piggyback the data packet? We don't want to multicast subsequent packets. The questions was raised asking if the solicitation should be sent to an "all nodes multicast", or to some special multicast which is a hash of the address (so that not all nodes need to listen to it). Another issue raised was that the additional bytes in the packet could create fragmentation problems. hinden [Page 15] IPng Implementors Meeting Minutes November 1994 After much discussion, it was suggested that we do not need a complex protocol to solve this, given that it is not a particularly serious sub-optimality in the current Internet. The group agreed to stick with the current mechanism. Next Meetings ------------- There will be two IPng implementors meetings at the December IETF. The first will be on Sunday December 4, 1994 at 1PM. The second will be December 9 at 9AM. hinden [Page 16]