Internet Engineering Task Force IPng Work Group Meeting Minutes Xerox PARC, Palo Alto, CA February 9 & 10, 1995 Introduction ------------ The IPng working group held a two day meeting at Xerox PARC in Palo Alto, CA on February 9 and 10, 1995. The meeting was hosted by Steve Deering of Xerox PARC. These minutes were prodced by Frank Solensky. [Questions or comments that came up in my own mind while writing up these notes are identified within square brackets like these. -- FTS] Core Documents -------------- The first item of business was to identify which of the IPv6-related documents are considered to be the 'core' set; that is, those that must be placed into the standards track before the IPng Area will be able to disband. The list of documents follows, with a preliminary timetable for the working group last call, as constructed by A.Mankin and listed in chronological order. They will be submitted into the standards track in approximately the same order, staggered so as to avoid overwhelming the community with too many documents at one time. The 'last call' on all of them should be issued before the Danvers IETF in April. (T ~= Feb 10) A Unicast Address Architecture T A Global Unicast Address Format T IPv6 Base Specification T + 1 week ICMPv6 T + 1 week DNS (AAAA records) T + 1 week IPv6 Address Architecture T + 2 weeks (pack authors + 1 wk) Discovery Formats T + 2 weeks (?) Discovery Processing T + 2 weeks (?) Transition Mechanisms + Routing Aspects T + 3 weeks Address Autoconfiguration T + 3 weeks Security Architecture ? Security Authentication ? ESP Encryption ? The following documents are considered to be part of the 'core' set as well but will be submitted as Informational or Experimental RFCs rather than Proposed Standards. BSD API T ? IPng Overview (including Transition Overview) T + 3 weeks Security API ? OSI NSAP Mappings (experimental) ? The following will be submitted as an Informational RFC independently of the working group. Discovery Requirements The following documents have been identified as not being part of the 'core' set and not considered critical path at this time. This DOES NOT mean that they are considered any less important or that the described functionality therein will eventually be designated as optional. Header Compression Mobility (Perkins proposal) Mobility (Simpson proposal) Mobility (Teraoka proposal) Explicit Route Protocol (ERP) FOOBAR DHCPv6 DNS Autoregistration These documents are in progress within other IETF Areas and have no impact on the dissolution of the IPng Area. OSPF RIP-II IDRP Other documents that need to be updated for support of IPv6 follow. It is unlikely that these changes will occur within the next couple of weeks, so the IPv6 documents will reference the IPv4 behavior of freely available reference implementations. IGMPv2 (IPv4 update to RFC-1112) MTU Discovery IPng Address Architecture ------------------------- B.Hinden is currently working on an update to this document and identified the following changes: - Add to the addressing model section some text about load sharing and unnumbered links. - Rewrite cluster address section to be consistant with pack address concept advocated by D.Estrin, Y.Rehkter and T.Li. Some questions about pack addresses were raised by S.Deering and forwarded to Estrin, Rehkter and Li. B.Hinden has written some new text based reading the pack definition and Deering's comments and made it consistent with the rest of the document. This text will be sent to Estrin, Rehkter and Li for review. - Reserve a 'well-known' link-local prefix for the link-local address to meet the requirements of the addrconf group. - A definition of a 'pack router' needs to be included. - wordsmithing changes. D.Haskin requested the addition of some text that explicitly indicates that the value of the address extension field within a pack address may be set to zero (as opposed to the definition of cluster address which did not allow zero values); this address would describe a cluster or pack that is contained within the a larger one. B.Simpson wanted to add a prefix to the intra-link scope address to indicate the media type in use, citing the case where a multi-homed host (ie: the 'not router') is connected to three different media: if it learns an address over each interface, each having the same value, it can't tell if it is one device that is connected over each interface or is instead different devices using the same address. However, this proposal didn't sufficiently take care of this case where all three media were all Local Talk, so the recommendation was dropped. Someone asked if the neighbor discovery section still needed to reserve the 'all hosts' address since we haven't come up with a case where it would be used; the general consensus was that this should continue to be reserved. Intra-link multicast scope addresses: text should be added that the scope diameter is defined by the organization using the address as opposed to a placeholder for something to be further defined within this document. Scope levels for multicast addresses: as discussed at the implementor's meeting in San Jose, two multicast addresses using different scope values but equal through the rest of the address are considered to be separate and distinct multicast addresses. No attempt will be made to provide IPv4/IPv6 address translation on multicast addresses. This should be mentioned in the SIT document. IANA will be asked to either obtain a new 24-bit IEEE address prefix or request the donation of a multicast block currently associated with some company's unicast block for the use of 'well known' IPv6 multicast addresses. The mapping between the IPv6 multicast address and the ethernet address will be based on the low-order 24 bits rather than the current practice of 23 bits. It was suggested that the names 'intra-link' and 'inter-link' scope addresses be changed to 'link-local' and 'site-local' in order to avoid confusion. The precise term to be used for packs/clusters/ whatever will be selected by T.Li and Y.Rekhter. After these changes are made, there will be a working group 'last call' on the resulting document. Assuming no issues come up within the following two weeks, it will then be submitted to the full IETF list for its last call before being submitted for Proposed Standard. IPv6 Base Specification ----------------------- Flow IDs: The current version of the document specifies only that a flow ID value of zero is reserved and has no special handling requirements by the intermediate routers. S.Deering reports that the end-to-end working group had requested consideration of a requirement to use non-zero valued flow IDs on all TCP connections. They had suggested potential arguments for this approach but had not yet provided a detailed proposal for initializing the flow IDs or managing them all in router processing. The rough consensus among those present was that while this work is important, it wasn't on the critical path to getting early implementations going. F.Solensky asks if we might be putting ourselves into the chicken-and-egg IPv4 ToS dilemma: S.Bradner reminds the group that Proposed Standard is still a very early stage of the standards process so that this risk is relative small; in order to prevent this from occuring, we should not advance the document to Draft Standard until the field and its usage are specified. E.Nordmark pointed out that the spec states that the host learns the flow ID values from the routers but had no provisions for timing out the implied state mechanism behind this operation. R.Elz had suggested on the mailing list that if a router had not seen traffic over a given flow within three seconds, it should time the flow out; G.Minshall cautions that exclusine reliance on this could lead to the BSD ARP problem: a babbling flow cause routers to never time out an entry. D.Haskin was concerned that three seconds might be too small: use of a fixed low resolution timer (ie: BSD slow timeouts) would cause some percentage of flows to exist longer than they should while use of a high-resolution timer means that the router spends a greater number of cycles updating these timers; a longer time interval lessens this overhead. He asked for a ten second timeout instead, the rough concensus was to split the difference at six seconds. Outstanding question: a host reboots and forgets the state that it had set up earlier with other nodes. Is the host prevented from setting up a new flow as a result? People in the room generally felt that the amount of time it takes a host to reboot is almost always greater than the six-second timer, so this shouldn't be a major issue. A suggestion was made by the ERP authors that the originator of the flow should specify what to do when the router loses state. The end2end group indicated that this was not the case and that this occur as part of the flow setup protocol itself rather than using bits within the flow ID field to accomplish this. Text needs to be added pointing out that header compression should not depend upon the existance of flow ids: the two concepts are orthoginal. Explicit Routing Protocol (ERP): In San Jose, one of the work items was to replace the 'type 0' routing header with references to the Explicit Routing Protocol. The header format from ERP has been agreed upon and will replace the former 'type 0' routing header. However, the SDR WG is not ready to submit ERP's proposal for a last call, so the IPv6 base specification should not include specifics on the protocol processing of the ERP header. Minimum MTU/Reassembly sizes: Prior to this meeting, both the minimum MTU and reassembly sizes were 1500 (or 1492) bytes. Several compelling points came up during this part of the meeting that lead the group to lower both back values down to 576 bytes: - the LocalTalk problem: the maximum packet size for LocalTalk is 587 bytes. While there was a preference to recommend that media with small MTUs devise a link-level fragmentation/reassembly scheme that would take place only for that single hop, there was also recognition of the fact that the group did not have the means to mandate this; even if it did, it was unrealistic to believe that it would be feasible to upgrade the entire installed base. - Defining the minimum MTU at a relatively high value would lead towards fragmentation when a packet grows while in transit (ie: tunneling). Current MTU Discovery algorithms don't indicate when or how much packet growth occurs. - Use of a reassembly size greater than the minimum MTU could encourage people to not implement MTU discovery. Retransmissions would require the sending of multiple packets when the most likely case is that only a single packet was lost in transit. - While DNS was a large motivating factor for the large MTU sizes, people who had attended the DNS meeting earlier in the week indicated that anticipated future uses such as the exchange of public keys would necessitate moving away from UDP as the transport protoco, opting for either TCP or Transactional TCP instead. Other items: S.Deering is working on an update to the MTU Discovery RFC that includes changes made to the algorithms based on implementation experience. The new algorithm will also be incorporated into the IPv6 Base Specification. A suggestion was made that the MTU Discovery RFC update be written in a manner that did not limit itself to IPv4. A person relatively new to IPng was surprised to learn that the IPv6 header was not checksummed, others he had asked about this were equally surprised to learn that they had forgot the rationale. It might be advisable to add a paragraph that provides a description that the IPv4 checksum was itself not highly reliable and that the authentication header provides a higher degree of protection when it is used. A Unicast Address Architecture: ------------------------------- While some have reservations about the underlying approach, the document itself seems to be technically accurate and consistant. Someone asked if the document should be submitted as an Informational RFC rather than as a Proposed Standard; there didn't seem to be strong feelings one way or the other. The Working Group Last Call should be issued on the current draft as is. A Global Unicast Address Format: -------------------------------- S.Deering expressed concern that the plan places an emphasis on aligning address assignments on byte boundaries but didn't feel that this was a major issue. The Working Group Last Call can be issued on the current draft as is. ICMPv6: ------- Text indicating that the received 'Echo Request' message must be delivered to the upper layer needs to be softened: while it's true that an incoming 'Echo Reply' must be delivered up to a waiting process (usually the one that generated the original Request message), there is a lower likelihood of a process waiting to receive incoming 'Echo Request' messages. The description of the codes for the ICMP Destination Unreachable message (type 3) needs to be modified so that it is consistant with the most recent draft of Router Requirements which in some places obsoletes RFC-1122. Specific changes discussed were: - message code 6 should be removed - codes 0 and 1 need modification - use of the code 7 is to be resolved between the authors. - there was some question as to whether it is possible or important to make the distinction between the last hop router being unable to deliver a packet and any other router as implied in some of the other codes. Some feel that the transmission of an 'administratively prohibited' error message back to the originating host presents a compromise in security. If there is some other document either prohibits this or makes it a configurable option, this document should reiterate that recommendation. The description of the ICMP Packet Too Big message (section 3.2) should mention that it can be sent in response to a packet with a multicast destination address (as described in rule D.2 on page 6). Some Type and Code values are listed as 'TBD's; specific values need to be assigned before the document can be advanced. The description and format of a request/reply message pair for accessing the fully-qualified name of the node should be added: this came up as part of the discussion that removes the requirement for reverse DNS lookups (see 'DNS (AAAA records)'). Text needs to be added referring to the use of IGMP messages, either referencing a soon-to-be-written update to RFC-1112 or incoprorating their descriptions into this document. Message description and formats should be specified as well. [Minor: The phrase "node or router" appears in some places in the document; these should instead be either "node" or "host or router" as per the convention we've agreed to on the list. This may be occuring in other documents as well; I noticed it here just now.. -- FTS] [I've got "security SAID" jotted down and don't recall what this was in reference to. Another note reads "Source node isolated? Can get from IPv6 header" -- FTS] DNS (AAAA records): ------------------- There is a growing aversion to the continued support for inverse domain name lookups and reverse DNS in general: updating the reverse tree manually is becoming increasingly difficult task, updating it dynamically is very hard. Further, the continued support of reverse lookups may be creating a false sense of security. Recognition of these external factors lead the group to consider removing the references to the inverse tree from the current draft, stating instead that there is no inverse tree and providing the rationale. Drawing this line in the sand would then provide the IETF an opprutunity to face the question as to whether it feels that continued support for this is either required or even desirable. It was noted that this proposition would require that an alternative proposal be presented. An easily implemented alternative is the creation of a new ICMP request/reply message pair for requesting the fully- qualified name of a node that would be initiated when an application issues a gethostbyname() procedure call. This would require the node knows its fully-qualified name within the kernel and would represent a change to some systems. A major advantage of this approach is that the automatic DNS updates become easier since the reverse mapping tree does not also need to be updated. R.Callon notes that this is an improvement over reverse name lookups in that it relies only on the already existing routing infrastructure rather that both that and the domain name system (which in turn relies on the routing infrastructure for its updates). FOOBAR: ------- D.Piscatello has agreed to update to RFC-1545 but the time at which this could be completed is uncertain. The only issue identified during a cursory review of the document during the meeting was that the address family types had to be included: a more through analysis needs to be undertaken. BSD API: -------- There was a request for the addition of a timeout parameter on the addr2hostname procedure. [Page 15: "addr2hostname() performs an inverse lookup in the name service"... If the reverse DNS changes are made, this text would have to be modified. -- FTS] addr2ascii(): the buffer supplied must be at least 46 bytes, not 40 as listed. [After the meeting it was noted that the only time that the last four bytes would be in dotted-decimal notation is when the address is either IPv4-only or IPv4-compatible. In both cases, the "::" convention would prevent the resulting string from getting that large.] A reference to the "::" zero-suppression convention should be included for both addr2ascii() and ascii2addr(). Also, both functions should mention that the buffers holding the network addresses store them in network byte order. An explicit reference to the security API document needs to be added. Security API: ------------- References to BSD-specific features (ie: SIGURG) should be removed from the document. A general question came up about ICMP and security: if there is a goal to make all ICMP messages secure, it becomes problematic to take a node "out of the box" and have it interoperate right away -- generally, some manual configuration needs to occur in order for the node to be capable of decrypting the ICMP messages it receives. The mailing list last call on this document should be issued before the Danvers IETF. IPng Overview: -------------- While the document will be submitted as part of the core group, it will be as an informational RFC rather than a proposed standard. The Reverse Source Route section of the document needs to be updated to reflect some recent changes. There should be a mention of the fact that IPv6 Address Translation is considered as an area for further study, possibly with some mention of the guidelines for its use and its visibility. IPv6 Transition Mechanisms + Routing Aspects: --------------------------------------------- On Thursday afternoon, Bob Gilligan started the discussion on issues in the Transition Mechanisms spec. Jim Bound suggested that DHCPv6 be listed as one of the mechanisms by which a node could acquire an IPv4-compatible address. Bob agreed to make the change to the spec. On Friday morning, Ross Callon presented a list of transition mechanisms which he thought there was general agreement on, prioritizing them in an easy-to-hard order: - A "dual stack" node using IPv4 with native IPv4 addresses, and IPv6 with native IPv6 addresses. Can directly interoperate with both IPv4 and IPv6 nodes. - Dual node using manually configured IPv4 tunnels for exchanging IPv6 packets over IPv4 routing areas. - Dual nodes reachable only via IPv4 routers, using the IPv4-compatible (::FFFF:) address format with encapsulation and (auto-)tunneling to such nodes. - Dual nodes encapsulate to the 6-bone using an IPv4 well-known address (WKA). It was noted that if an host has an IPv4-compatible address assigned to it, it will be required to support automatic decapsulation on received packets and encapsulate transmitted ones. Ross also proposed that there is not general agreement on: - Header translation. - Use of the IPv4-mapped (::) address format in header translation. There was general consensus that the transition mechanisms spec should specify only the four items on Ross's first list (IPv4-compatible addresses and tunneling), and should not specify or discuss the items on the second list (IPv4-mapped addresses and header translation). There was consensus that the IPv4-mapped address format would continue to be "reserved" in the Addressing Architecture document. There was some further discussion of the organization of the transition documents. The group agreed that the Transition Mechanisms spec should be made into a single standalone document by adopting a short (approx 1 page) introduction from the Transition Overview document, and adding some explanation of routing from the Routing Issues document written by Ross Callon and Dimitry Haskin. Ross and/or Dimitry Haskin agreed to donate the words from the Routing Issues document. Bob Gilligan agreed to make the necessary changes to the Transition Mechanisms document and re-issue a new internet-draft within 3 weeks. There was some discussion of the SIT Overview document. There was agreement that much of the information from this document could be merged into the IPng Overview document that Bob Hinden is authoring. Someone suggested that the document should note that automatic tunnels are always IPv6 over IPv4 tunnels, while manually configured ones can be either IPv4 over IPv6 or vice versa. There was some discussion on the use of a well-known IPv4 address as the default tunnel to reach the 6-bone. An IPv6 island ('host' being the degenerate case) that needs to send IPv6 packets across an IPv4 stub/area to reach a destination on the 6-bone could do so by tunneling to the well-known IPv4 address. A dual router bordering the 6-bone can advertise reachability to this address into the IPv4 area. Greg Minshall noted that there may be a patent issue with Peer Logic when using this approach; Bill Simpson notes ham radio as prior art. Address Configuration: ---------------------- Automatic address configuration: There is a growing consensus that the attempt to design a single mechanism for address autoconfiguration that covers all scenerios from the dentist's office to the large, centrally administered site is too ambitious. There will instead be two separate configuration mechanisms developed and proposed; one for the "plug & play" (stateless) environment, one for dynamic protocols with central administration (stateful, DHCPv6). The document that will be submitted as part of the core group is the stateless version so that early implementations may proceed; work on the stateful version will continue within the DHCP group. The working group will change the name of the document to "IPv6 Stateless Address Autoconfiguration" so that there is less of a chance that this proposal is interpreted as being the only manner in which IPv6 will perform address autoconfiguration. The order in which operations occur in the stateless case are: - Address autoconfiguration - Router advertises subnet parameters (ie: max ttl) - Service Location - Auto registration with DNS Stateless address autoconfig breaks down into two cases: the passive case being where the host performs the concatenation between the prefix and its address token; the active case where the host sends a query to the router (or some other server) which in turn determines the full address (via a concatenation operation, DHCP query, etc) before returning it to the host. A drawback of the first approach is that the mechanism becomes difficult or impossible to change once it is deployed. The Passive Stateless autoconfiguration approach also requires that one and only one link-specific algorithm is used for the host to select its address. These potential drawbacks were not considered to be showstoppers and the passive mode was agreed to. DNS Autoregistration: S.Thompson gave an overview of the discussions of the DNSIND working group that took place earlier in the week. There was progress made on the coming up with an approach for automatic name registration and address configuration. Some of the security details still needed to be worked out, along with some concern that the stateless approach would be vunerable. The group felt it should limit itself to the IPv4 approach at this time, working with the DNSIND group to be sure that the hooks that they determine are necessary would be available. S.Deering notes that name registration need not be bound to the address allocation. Router advertisement messages in the passive stateless case would indicate which address mode was in use, if further configuration was necessary and includes an indication of valid and deprecated subnet prefixes. It might be necessary to override this information, and allow for the case where the site cannot reach the DHCP server. The host behavior in the passive case is as follows: - on initializatiom, the host forms the link-local scope address and sends a router solicitation message. - The router advertisement message indicates 'stateless' or DHCP (the host waits 3x max router solicitation interval, then performs DHCP queries). - on receiving the address prefix router advertisement message (includes the lifetime field): > if it is a renewal, validates existing address with existing prefix, > else if new, adds new address with new prefix, > otherwise, deprecates the address. This last point was dropped however, when it was determined that it could cause problems when multiple routers were present: depreciation should only occur when explicitly requested. - when the entry times out (the router is down and stops advertising; the prefix is no longer advertised but not explicitly dropped either), the host accepts packets addressed to the old address. The old address gets lower priority than the link-local for source addresses. Existing open connections (ie: TCP) would continue to use the old address; new incoming connections get the link-local address instead. The main body of the text will describe the general approach of the proposal and indicate that the media-specific details will vary. An appendix will be added that describes how address configuration occurs within an IEEE-style address environment as an example. The goal is to have a new version of the draft available in two weeks, three at most. Neighbor Discovery Format: Neighbor Discovery Processing: ------------------------------ The current Format draft included the change discussed at the San Jose meeting that set the granularity of the LifeTime field in the I-Am-Here advertisement message at one millisecond rather than one second in order so that it would have the same granularity as that used for SNMP timer values. There was, however, some question as to what field width was agreed upon at that meeting and what that width should be. In his capacity as Area Director, S.Bradner advised that the field should be changed to a 32-bit value so as to avoid future problems should a maximum interval of ten seconds eventually prove to be too low for some situations. Rather than using the Known-Identifier field to sometimes refer to an identified assoicated with the sender and sometimes the receiver, it was suggested that these be modified into separate Source-Identifier and Destination (or Target)-Identifier extentions so as to clarify the specification and the protocol. The format would be identical to that of the current Known-Identifier extention. An extended discussion was initiated by an observation that the IPv6 address is not included within the General Solicitation message; this broadened into a philosophical difference in opinion over proxy servers. A.Conta and E.Nordmark took the position that proxy servers offer greater flexibility while S.Deering and B.Simpson saw them as compromising the overall robustness and security of the network. It was decided that this aspect of the document would be left unchanged for now; support for proxy service is a higher-level issue that reaches well beyond the scope of this individual document. There was some question within the group about the situations in which the Node Heard and System Heard messages would be used; B.Simpson offered a 'half-link' scenerio in which communications between two hosts and a router could take place but two-way exchanges were not guaranteed -- a common case within ham radio stations -- and allows the two hosts to learn when they can avoid the router in the middle and communicate directly. The rough consensus among those present was that while the proposal itself is intriguing, it was a problem that deserved greater attention and needed a more exhausitve explanation than that currently provided within the Neighbor Discovery Message Formats document. Further, since the documents that are related to mobility are not going to included among the core set, the group requested that references to the Node Heard messages be omitted at this time, replaced instead with a two or three paragraphs that indicate that the protocol can be extended to support mobility. System Heard messages would be used over those link-level protocols where the media- specific problems it is designed to solve are likely to be a concern. B.Simpson expressed a concern that these changes might cause support for mobility to never be deployed; S.Deering reiterated his goal of ensuring that no shipping IPv6 router is unable to support mobility, S.Bradner later reminded the group that Proposed Standard documents are not considered to be in their final form. Another discussion took place over the proposed usage of General Soliciatation and General Advertisement messages for address resolution. Two concerns were expressed: the first being that address resolution has traditionally been implemented in a manner that is cognizant of the characteristics of the link layer protocol rather than using a general-case approach for all media, the second being that the proposal requires the exchange of four messages since the receipt of a General Solicitation message could not instanciate address mapping in the route cache for the sender of the General Soliciataion message. The group wanted to limit discovery to two messages in order to avoid sending more multicast/broadcast messages than IPv4 ARP Request/Reply exchanges and suggested that the approach currently described in the Discovery document be moved into "IP-over-" documents, to be used only in those environments where it would be beneficial.