CURRENT_MEETING_REPORT_ Reported by Robert Hinden/Sun Microsystems Minutes of the IPng Working Group (IPNGWG) Introduction The IPng working group held five working group sessions and one implementors meeting. Working group meetings were held on Monday (two sessions), Tuesday, Wednesday, and Friday. The implementors meeting was held on Sunday prior to the working group meetings. The minutes were produced based on notes taken by Ross Callon, Frank Solensky, Dan Harrington, and Robert Hinden. Thanks to Jim Bound and Steve Deering for reviewing and commenting on the drafts of these minutes. IMPLEMENTORS MEETING, SUNDAY Terminology Notes The minutes also adhere to convention recently agreed to on the mailing list for the terms `node', `router' and `host'. `Nodes' are devices that are capable of receiving and sending packets and can be divided into two types: `routers' forward packets that are not directly addressed to it while `hosts' do not. Routing Area Report As the Routing Area Director, Joel Halpern made a brief presentation on the status of routing protocol support for IPv6. Work is in progress for making changes to IDRP as the primary means of providing inter-area routing and the working group believes that most of the changes are relatively straightforward. The OSPF and IS-IS groups are also confident that the changes they need to make to provide intra-area routing support for IPv6 are well understood and are working on draft documents. The RIPv2 Working Group has a proposal ready. Joel expressed some reservations about allowing RIP to continue into IPv6, largely because of some of the ways it has been come to be used as opposed to problems with either the protocol or the underlying distance-vector algorithm (i.e., hosts using the information seen in passing RIP packets to update their own forwarding tables). He was planning to meet with the RIPv2 group during the week to listen to their arguments in favor of continued support and was reminded by Bob Hinden that the simplicity of the protocol itself is one of its strengths for non-complex environments and by Robert Elz that even if use of the protocol is going to be discouraged, the document should still be written so as to reduce the likelihood of incompatible implementations springing up as the result of it not being documented. [Reporter's Note: Subsequent to this session, the RIPng work was approved by the Routing AD and the RIP working group will take on this task.] ESP Bit Alignment Randall Atkinson described some of the concerns about Encapsulated Security Payload (ESP) proposal raised during discussions within the security area; one of the main ones was the specified alignment of the fields: some of them currently are aligned on 32 bits but not 64-bit boundaries. The consensus was to require the addition of algorithm-dependent padding after the security association ID (SAID) and immediately before the protected data to maintain 64-bit alignment, recognizing that this pad may be relatively long in some cases. Padding may be random bits rather than zero-filled to make it harder to crack. There was a discussion about considering the possibility of ``Security Lite'' in which certain specific packets are authenticated, but not all packets (for example, security critical ICMP packets such as redirects are authenticated). The idea is to make it much harder to break in with minimal performance impact. [Reporter's Note: The remainder of this presentation was repeated at the Tuesday working group session. See that section of the minutes.] API v4-v6 commonality Jim Bound asks about the APIs: What happens when an IPv4 application wishes to interoperate with a server running over IPv6. Security API The question was raised on whether separate API documents should be written: one that presents the general API and another with security extensions. The group preference was to have a single document with an appendix that describes the details when using DES-64 so as to reduce the likelihood that implementations will be written that can only support one. Multicast Address Mapping Steve Deering asked the group if it might be advisable to change the manner in which multicast IP addresses are mapped into Ethernet addresses. The current practice is to retain the low-order 23 bits of the class D address which penalizes performance due to the additional masking operations. The group's preference was to reserve a full block of Ethernet numbers from IEEE and use the entire 48-bit MAC address as the low end of the 64-bit IPv6 address. MTU Size The general consensus of the group was to recommend changing the MTU to 1500 bytes from the current 512, Ran Atkinson pointed out that anything larger makes life painful for existing satellite communication (SATCOM) implementations. Justin Walker reminded the group of a recent discussion on the mailing list regarding packet fragmentation over Apple's Localtalk if the MTU is going to be larger than 587 bytes but the group preferred to use the larger value and request Apple to develop some means of supporting single-hop fragmentation and reassembly rather than define IPv6 with the smaller MTU. Justin offered to bring this up to the right people within Apple. The minimum buffer reassembly size remains at 1500 bytes. This would be reiterated within the regular working group sessions to see if any significant issues came up as a result. Route Reversal by ICMP or Destination The SDRP group accepts the idea of having a bit specify that the route is believed to be reversible and is to be interpreted as a hint as opposed to a mandate. If the bit is not set, the reversing system realizes that the route is not to be reversed; that is, it must look it up on its own. Multicast API A question came up in regard to the API used on a router when originating multicast packets: did some argument need to be added that specified which interface would be used to transmit a packet? The answer was no: multicast uses a similar API as IPv4 in that a socket specifies the source address through a bind() call, this determines which interface is to be used for transmitting packets. If an attempt is made to send raw packets to an unbound socket or one that is bound to INADDR_ANY, it is an error. The ``all-hosts'' group is defined to be all nodes minus all routers. Thus, a router by definition is not a host, and must not join the all-hosts multicast group. Routers join all-routers and all-nodes. Hosts join all-hosts and all-nodes. TCP MSS None of the current draft specifications point out the fact that TCP will have to advertise a different Maximum Segment Size (MSS) when used with IPv6 than with IPv4, over a path with the same MTU, due to the larger IPv6 header size. This needs to be documented. Miscellaneous Should implementations use IPv6 preferably over IPv4? How do you know whether the implementation is doing IPv6-special features? The current idea is that use of IPv6 encapsulated over IPv4 as the default. There is an argument that it will be easier to deploy IPv6-capable dual-stack hosts if we make the initial deployment as painless as possible. Also, we know for sure that for the next year or two IPv6 will be lower performance and less robust than IPv4. Thus, if we really want folks to deploy IPv6 soon, we should not require that folks actually use it in those cases that IPv4 would work well. WORKING GROUP, MONDAY Steve Deering introduced the meeting. The goal of the meeting was to review the specifications and resolve open issues. There were no overviews presented, attendees were expected to be familiar with the documents. Agenda o Review results of implementors meeting o IPv6 base protocol specification o ICMP/IGMP o Addressing architecture o Unicast provider address formats o NSAP addressing o Security o Neighbor discovery o DNS specification o Flow IDs o Header compression o Proposed new header types Review Results of Implementors Meeting Robert Hinden gave an overview of the IPng implementors meeting held at Digital Cambridge Research Lab. The implementor's meeting does not make decisions regarding protocol issues. Thus, any apparent agreement at an implementors is not a binding agreement, but rather is just a recommendation to the working group. The purpose of this review was to present the recommendations to the working group and gauge the consensus on them. Addressing model: The implementor's meeting recommended that we stay with the IP model of one address per interface. However, a single address can be assigned to multiple physical interfaces on the same physical subnet if the implementation treats the multiple interfaces as a single aggregate and hides the details of this from the Internet level. Also, routers may have unnumbered interfaces on point-to-point links. For router to host point-to-point links, the host must have an address. The working group agreed to this model. Cluster addresses: Keep them in the specification as ``reserved.'' Not actually used until there is a very clear proposal and understanding regarding how they may be used. Cluster addresses are currently used for system discovery, this will need to be resolved. A suggestion was made to use the ``pack'' model to augment cluster addresses. After some discussion the working group agreed that the ``pack model'' should be used and the next version of the addressing architecture document should be updated to reflect this. Neighbor interactions: We will continue with the approach in Bill Simpson's draft. This continues a request/response model (similar to the current ARP model), but implemented as extensions to ICMP. This was agreed to by the working group. Host knowledge of prefixes: Agreed that host will learn the subnet prefix(es) to be used from routing advertisement. Routers must be able to include these prefixes in Router Advertisements. It did not make the minutes, but some folks recalled that a router should be able to redirect a host to a different prefix (for example, when there are multiple logical subnets on a single physical network). Also, there was a preference for a router to not advertise any prefix, in which case the host will need to go to a router. This is another case in which the router may need to be able to redirect a host to an address which the host does not think is on the same subnet. There appears to be a bit more work needed in this area. Scope of Discovery: Remove the proposed service location extensions from the discovery document. The details (e.g., specific packet fields) of system heard messages are still under consideration. System heard is only needed in some circumstances (e.g., wireless links with some particular characteristics). What fields should be in the system heard message is being discussed. This was agreed to by the working group. ICMP: There should be a ``packet too big'' message as a separate error message, and not just a subtype. The 16-bit error pointer can in theory point beyond the end of the packet. These can be useful with IPv6 because of the sequence of header types. Thus, the pointer tells you which header it was that was in error. We need to be clear and unambiguous regarding where the pointer should point for any particular error. This was agreed to by the working group. ICMP redirects are to be described in Bill Simpson's system discovery specification. This was agreed to by the working group. The ICMP error message is to include a maximum of 576 (or whatever the min MTU ends up being) bytes of the offending message. Redirects only need 40 bytes, but for simplicity should do the same thing as other ICMP messages. This was agreed to by the working group. Auto-address assignment had a 16-bit field which provided the address lifetime. It was decided that this was not big enough, so the field has been expanded to 32 bits, and a value of ``infinity'' defined. This was agreed to by the working group. There was a long discussion of transition and testing. The auto-encapsulation rules are to be left as currently defined. These issues are in general likely to cause more discussion. There was discussion regarding DNS. It is desirable to allow implementations to fall back on local files (for example, to allow initial testing of hosts before DNS is updated). This was agreed to by the working group. Text representation of addresses was discussed at length, and will be left as is. This was agreed to by the working group. Every host needs to be able to reassemble a datagram up to 1500 bytes. The minimum MTU remains at 576 (the minimum MTU includes the IP or IPv6 header). Alan Openheimer of Apple offered to discuss the implications of a larger MTU on localtalk implementations. The issue is that localtalk only supports 576 (or very slightly larger) packets. Thus, if the 576 MTU were increased (e.g., to 1024 or 1500), systems with local talk interfaces would need local (subnet-dependent) fragmentation and reassembly. One of the motivations for increasing the MTU size is that DNS is looking to add new capabilities which require a large minimum MTU size. In general, with IPv6 we are trying to avoid internet-layer fragmentation. This implies that a larger minimum MTU might be a good idea. PPP can support (more than) 1500. There is an issue with SLIP. Also, there is a latency issue when a small packet gets behind a large packet on a slow SLIP or PPP link. Ran's satellites have a problem with greater than 1024. If we agree on greater than 1024, then they will have to tunnel, and pay the price. Bill Simpson would like link-specific F&R over all or most links. The rough consensus of the working group was for a minimum MTU of 1500. Reversing Source Routes: The implementors meeting recommended a bit in the source route which states whether the source route is believed to be reversible. The degree to which this is ``a hint'' versus ``required'' in each direction was discussed. 1 = OK to reverse. 0 = ``don't reverse.'' This was agreed to by the working group. Packets greater than 64k: Consensus is to use a hop-by-hop option to use a length field of zero as a flag which says that an option includes the real length field. This was agreed to by the working group. IPv6 Base Protocol Specification Steve Deering reviewed issues with the current base protocol specification. Expected future changes: o Have chosen not to split up the document. (Will have ``the basic set'' of headers.) o Replace type 0 routing header with ERP There was a discussion of encoding of the extension headers. Some folks would like a common format in the sense that each header starts with a (implied type and) length in the same place and format. For example, this could make it simpler to build certain ``not entirely router'' entities, such as header compression devices which can compress only some types of headers (and does not want to know anything about other header types), or fragmenting bridges. The consensus was to be to leave things unchanged. Options have an encoding which tells you what to do if you do not understand the option. This is not necessary for things that are required. Tracy Mallory is concerned that this is not extensible, in the sense that if we define a new routing header type in three years old IPv6 routers will not know how to deal with the new field. Jim Bound would like a common format to speed up header parsing. Routing Header Format, continued: Robert Elz proposed a piggy backing format, which allows smallish packets to be combined/nested. Headers start with an 8-bit ``next header,'' 8-bit ``protocol'' (this header), and a 16-bit length. His proposal allows nesting: two packets which use the same IPv6 header can share a header, such that the common header is only sent once. We could imagine a case where a packet does not actually carry anything, but is used, for example, to initialize or continue a flow. Thus you want the packet to actually end after some internet-layer (IPv6-related) header. This requires that a possible value for next header should specify ``no next header.'' Jumbograms: Where does this exceed existing format: Fragmentation header. The proposal is that fragmentation of a packet which is greater than 65,535 be prohibited. IPv6 deprecates Fragmentation -- this is included only for compatibility with old IPv4 stuff (both for header translation and also for old applications which are designed to run over IPv4). These old applications cannot run with bigger than 65,535 anyway, thus there is no need to support fragmentation of datagrams larger than 65,535 bytes. This resulted in a discussion of whether jumbo gram support is needed at all. There was a clear consensus that there is no need to change the format of the fragmentation header in order to support fragmentation of jumbo grams. TCP MSS needs to be adjusted (since IPv6 header is larger than the IP header). Minimum MTU is being raised to 1500, based on this mornings discussion. This once again makes the minimum reassembly buffer size equal the subnet MTU. Destination Options: These are for ``intermediate destinations,'' meaning routers listed in the source routing field. The end to end options can be renamed for this, and the location (before or after the routing header) will tell you whether it is for the ``real'' end, or for the next ``mentioned in source route'' router. Tunneling (IPv6 over IPv6): There has been lots of mail on the mailing list. The underlying encapsulated link is treated just like a normal data link (this observation can be used to derive all or most details of the tunnel operation). There is an issue regarding whether you want to ``expose the TTL of the tunnel,'' by copying the TTL between the two IPv6 headers, so that traceroute shows the intermediate hops in the tunnel. Clearly there are some cases where the folks in the middle do not want to expose their topology. Thus, there will be some cases where it is appropriate to decrement the outer TTL by one for the entire tunnel. What if I am doing security type tunneling? Answer: Clearly there is a need for the ``opaque tunnel'' (decrement by one) type of tunnel. The question is whether there is a need for the other kind as well. If we support more than one kind of tunnel, then the appropriate place to control which type is at the tunneling point. It is proposed that the specification allow both forms of tunnel. It was pointed out that regardless of what the specification says, folks are likely to implement both. Steve is proposing that the specification should recommend that both be implemented. Tracy Mallory pointed out that this is not of much use unless the link layer of the internal net is returned. Also, the address space used interior to the tunnel could very well be different, resulting in uninterpretable errors. Also, when there is a configuration error, the encapsulating end of the tunnel might put in its own (large) TTL, and the de-encapsulating end of the tunnel might copy this into the packet header, resulting in the TTL getting larger as a packet traverses its path (in principle a dangerous thing). Thus, if we have two types of tunnels, there is the possibility of (due to an error) confusing the two types. There are ways that we could indicate in the packet which type of tunnel is being used. ICMP/IGMP Specification Steve Deering reviewed the current ICMP/IGMP specification. There is a new specification, which just came out (on xerox Parc FTP), to become an Internet-Draft soon. IGMP is merged into ICMP. The latest version of IGMP is being used. Packet too big is no longer a subtype of destination unreachable, but rather is its own ICMP message type. Unknown Header Type is changed from unreachable to be a subtype of Parameter Problem. Redirect is removed from ICMP and put into neighbor discovery. Should there be a redirect per flow/traffic class? There should be a new protocol type for IPv6 ICMP. WORKING GROUP, TUESDAY Addressing Architecture Bob Hinden reviewed the remaining issues with the addressing architecture document. o Text formats for addresses o Cluster addresses o Representation of the default route There is an issue regarding the use of colons in e-mail addresses (some folks currently use IPv4 addresses in their e-mail address). One answer is to not use IPv6 addresses in e-mail (it is getting a bit big for ease of use). Another option is to fix SMTP user agents to accept colons (they are not used otherwise in e-mail addresses, but some existing software will not like them). Some folks think that this is a non-problem, and if we sit here and list all possible characters we will be wasting time. The consensus (not so rough) was that we like the address text format the way that it is currently defined. Cluster Addresses: This is a prefix of length ``n'' bits, followed by 128-n bits of zero. An alternative is the ``Pack'' addresses. For any particular cluster/pack: Take any specific unicast address (which is appropriate for this topological part of the network), assign it for use in this way, and use it as a cluster address. The pack address approach therefore avoids the problem of requiring that the prefix not have a trailing zero (since this would create an ambiguous cluster address), but requires that systems which need to know their address and also their associated cluster address will need to be configured (or auto-configured) with two complete addresses, rather than an address plus a prefix length. However, this ``Two-Address-Configuration'' is probably a good idea regardless of which format is used. A problem for cluster address approach is that: (i) you effectively lose one bit at each level (the last bit at each level must be ``1''); (ii) If you add a new level split in the middle, you may have to renumber (and also lose the bit in the middle). The only way to guarantee that you will not have to renumber in this case is to only use addresses with ``1''s in all bit positions, which is clearly impractical. The consensus therefore is to use the Pack approach (although not necessarily the name, which appeared to be less popular than the technical approach). Proposal that the zero length prefix be used for default unicast route. Anything that deals with multicast will need to announce reachability to a longer prefix to match multicast routes (which will automatically take precedence over the zero length prefix). Unicast Provider Address Formats Yakov Rekhter presented the proposed unicast provider address formats. An address registry can have multiple blocks of addresses assigned to it. The IANA is the highest level Internet address registry. Bill Simpson proposed to not fix the provider based address to always use a particular three bit prefix. Rather, just assign some blocks for this purpose. Steve argued that the three bits is a coincidence, and we have really done what Bill suggests (and it is just a coincidence that the first three bits always happens to be the same for currently assigned unicast provider based addresses). It was pointed out that this needs to be very clearly described to avoid misunderstanding. Thus this discussion is really editorial (we want to make sure that the document is clear). All that routers should assume about address formats is that they are doing longest prefix match, on bit boundaries. A number of editorial comments have been received, which Yakov will fold into the document. The standard topological hierarchical address discussions (particularly with respect to multi-homed stub domains) were repeated. It was agreed that the ``actual allocation'' draft should list actual providers/address registries, and the address prefixes that are assigned to them. These might happen to be assigned geographically/topologically, with space left for expansion, but we do not want to stress any geographic basis of this. NSAP Addressing Alan Lloyd presented a ``teaser'' (ie, introduction of issues to be discussed) for the NOSI BOF. Alan's addressing goals: To provide harmonization 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. 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. Migration idea: (1) consolidate longer NSAPs into Internet NSAPs. (2) (I did not get the rest of this, it flew by rather quickly). Action items: Get IETF and IANA to do this. Get ISO to assign addresses appropriately. Questions and issues regarding this proposal were deferred to the NOSI BOF. No consensus was sought at this meeting. However, Bill made sure that he voiced his disagreement now, since he is likely to miss the NOSI BOF. Security Ran Atkinson discussed security issues. Security causes a performance impact. May cause ``packet bloat'' and ``kernel bloat.'' Common encryption for IPv4 and v6 is impractical (thus you cannot translate encrypted packets). This is particularly caused by the lack of willingness for the IPv4-security group to accept 64-bit alignment. Padding and alignment (do we want to give up bits in order to keep everything 64-bit aligned in IPv6?). Some encryption algorithms require padding to a natural block size. The consensus at the implementor's meeting was that the 64-bit alignment was worth maintaining. A new format is proposed to ensure proper padding. This can require three pads (one to ensure that encrypted fields start on 64-bit boundary, one to ensure that the protected data start on a 64-bit boundary, one to ensure that the encrypted data ends on a proper boundary for the encryption algorithm being used). ICMP for IPv4 uses a different protocol ID than ICMP for IPv6. Do we distinguish different sorts of encrypted data (encapsulated IPv4, IPv6, ICMP-4, ICMP-6, UDP, TCP, IGMP), or just all as IPv6-packet-contents? Straw Poll: Where should the next header field be: at the beginning of encrypted data, or at the end? Straw vote was just about even, with ``don't care'' being the largest plurality. When including part of a discarded packet header in an ICMP error report, the authentication of the interior (discarded) header is not likely to work. Thus do not check it. (note that the same comment applied to the checksum for IPv4). A faster alternative to MD5 is being investigated. This needs to be checked carefully in order to ensure that it is actually secure. One advantage of MD5 is that it is commonly used elsewhere (e.g., SNMP). On the other hand, MD5 is already considered to be relatively weak. Suggested to be able to authenticate ``security critical'' packets for ``less processing intensive'' partial security. The goal is to avoid paying the performance loss of encrypting all packets, but still be significantly harder to break than no security. WORKING GROUP, WEDNESDAY Neighbor Discovery Dead Node Detection needs more explanation. Negative advice from other layers is the only way to expire a cache entry early (we do not depend on symmetric paths, this means that receiving a packet on the reverse path does not ensure that the forward direction works). If TCP discovers that it does not get an ACK after multiple tries, then something is not working, and it is a good idea to invalidate the associated cache entry and re-solicit router discovery (although there are many possible causes of this other than the first hop router being broken). Link layer down indicators clearly should be used to invalidate a cache entry. There was some debate regarding use of good and bad higher level information. It was argued that receiving a TCP ACK ensures that the TCP packets actually arrived at the destination, which in turn ensures that the forward path works (including the first hop router). Another argument for using higher layer information to shorten, but not to lengthen, the cache timeout is that we are more interested (in case of doubt) in shortening the timeout: We need to find failed routers quickly. On the other hand, assuming that the general timeout period is set to imply that router discovery results in a light load on the network, then there is not much to be gained by lengthening the period. However, if you shorten the timeout period considerably, then you could lengthen when an ACK is received. In this case the host would re-solicit very rapidly if it ever failed to get the TCP ACK. Clearly this only works for TCP. We are agreed that IPv6 hosts MUST not listen to RIP or OSPF packets. It is proposed to change the lifetime field to hundreds of seconds. This is because there are some environments where first hop loss needs to be detected within less than a second (and where the network administrators are willing to pay for the extra network/host/router capacity required to do router discovery more often than once a second. Thus, the standard should make this possible. Note that router discovery is not intended to indicate that you are using the wrong first hop -- rather, this is the purpose for the redirect. If the cache is timed out, the host does not re-solicit until it has a packet to send. At this point, the host should transmit the packet to the old entry even if it has timed out (and re-solicit router discovery at the same time): If the old entry still works, then this is the right thing. If the old entry is a black hole, then there is no harm in also sending the packet in addition to the re-solicit. Current Text: For communication from Router to Host, Host to Router, or host to host, if you have a packet to send and no entry, you send the packet to the IP unicast address, using a multicast link layer address which is a (well-known) hash of the IP address. Then send a solicit. Note that if the TCP ACK returns, then more TCP packets may subsequently be sent using the same method. Proposed at Boston: Do not transmit the data packet. Buffer the (most recent if multiple) data packet while doing the solicit and waiting for the advert. However, this should be clarified/extended by allowing ``semi-expired'' cache entries, which are old enough to cause a solicit when used, but which are young enough that we might as well use then to forward packet (preferentially to dumping the packet, or buffering them). Some folks wanted to think about this, given that it is a somewhat new proposal. Gratuitous advertisements (advertisement without a corresponding solicitation): A motivation was for a machine with two interfaces on the same link, that when one interface fails they want to send a ``gratuitous reply'' immediately on the second link, to get arriving packets to go that way (either by advertising the second link address, and/or by actively invalidating the first entry, perhaps via using a lifetime of zero). An alternative is to change the link layer address of the second link to be the same as the first, but this does not work for some hardware. There appears to be a consensus to allow unsolicited advertisements, but solely for the purpose of flushing previous advertisements. This must not check the mac address, since the ``cancel previous advertisement'' may come from the systems other mac (the one which is still working). Questions: Are there other concerns? The following list of topics of concern was compiled: o The system discovery draft should have no mobility in it (for clarity purposes) (the mobility protocol is not yet even close to agreement). One motivation was to simplify initial implementations. Another reason is that mobility is not yet agreed. This was vigorously discussed, but no resolution was reached. [Reporter's Note: This was discussed and resolved in the Friday session.] o There should be no reference to cluster addresses. In some cases things are called cluster addresses when they should be subnet prefixes, or just prefix. With this agreement, the comment become editorial detail. o Change identifiers (changing prefix on a link to a new prefix). This got changed to a way to tell hosts that a prefix is going away. This is also used in a remote redirect (which says that this old prefix will not be routeable anymore). Note that remote redirect may be used both for mobility, and also for some other purposes related to SDRP and policy. o ``Target ID.'' o Hop cache description does not belong in the specification (but this has already been removed from base s.d. specification and moved to an appendix). Thus this comment has been resolved. o Routing information extensions are needed to tell a host which stuff is attached to the directly attached subnet. o The process document talks about having a random solicitation delay. The reason for this is to avoid having everyone expire the same cache entry at the same time and all re-solicit at the same time. o Cluster bit -- one comment did not know why this is there. o Why do we not use solicitations to create a cache entry. o Source address selection mentions something about longest match. o How is the source address specified and what is the packet format? A different packet format was also proposed. o Redirects. including remote redirects. o Hop Limit advertisement. o Static routes should be discussed in processing document (there already is a discussion of this). o Choosing a source address. o Maximum time intervals -- we should allow a wider range. o Two things in the document do not belong: A whole bunch of implementation details should be moved to an appendix (some already have been). o Minimum advertisement interval appears to be too large. o General point: Some of the things in the document are oriented towards mobility. This has not been settled yet. o More fields should be added to the general advertisements. o A concern about the packet format and use of TLV. It was not possible to resolve all of these open issues during the time remaining. Therefore, the Friday morning implementors meeting was changed to be a ``real'' working group meeting, a larger room is being solicited, and we switched to considering DNS. DNS Specification Sue Thompson reviewed the issues with the current IPv6 DNS specification. A new Internet-Draft was sent out and did not get any response, except for one comment that it was very well done (from Bill Simpson). Inverse lookup is based on nibble boundaries. This is the only known issue (since bit boundaries would be nice). An approach has been proposed to do the reverse lookup in two queries, using two different trees. This will be discussed in more detail in the DNS group. We agreed that if the DNS folks fail to agree on the new scheme quickly, then we will go with the nibble boundary. It was also pointed out that folks are not maintaining the inverse tree particularly well today, and thus we do not want to ask them to populate two reverse trees. One suggestion was made that it is not a good idea to be able to map addresses back into names. For example, this is likely to be impractical to automate, and automating DNS tree maintenance is critical to really large scaling of IPv6. This discussion was referred to the DNS group (which is meeting later in the week). WORKING GROUP, FRIDAY Auto-Address Configuration A proposal was made by Steve Deering that we refocus the work on auto-address configuration. Specifically that the ADDRCONF Working Group should only focus on a simple IPng stateless auto-address configuration mechanism and that all other work in this area be done using DHCP. This implies that the DHCP working group should be chartered to develop IPng specific mechanisms for DHCP. There was a lengthly and heated discussion. A rough consensus emerged that it made sense to pursue this path of supporting a very simple auto-address configuration utilizing router multicasts of prefixes and hosts using the prefix with local information to create an address as long as there would be a escape mechanisms to require the hosts to contact a DHCP server. The IPng working requests the ADDRCONF Working Group pursue this. Mobility There was a general agreement that while it was important that there be mobility in IPng, that there was no consensus on which approach to follow. As a result the group agreed to remove mobility specific items from the current discovery drafts. Core Specifications The IPng area directors request the working group to define which are the core IPng specifications. The definition of core was that these be the specifications which when completed and submitted for proposed standard, the IPng area will disband. The following documents were considered by the IPng working group to be part of the core set of IPng specifications: IPng Specification R. Hinden, Editor, IPng Protocol Specification, Internet-Draft, draft-hinden-ipng-ipv6-spec-00.txt, October 1994. Addressing Architecture R. Hinden, Editor, IPng Addressing Architecture, Internet-Draft, draft-hinden-ipng-addr-00.txt, October 1994. Y. Rekhter, T. Li, An Architecture for IPv6 Unicast Address Allocation, Internet-Draft, draft-rekhter-ipng-arch-IPv6-addr-01.txt, October 1994 Y. Rekhter, P. Lothberg, IPv6 Preferred Unicast Address Format, Internet-Draft, draft-rekhter-IPv6-address-format-00.txt, November 1994. Internet Control Message Protocol A. Conta, S. Deering, ICMP and IGMP for the Internet Protocol Version 6 (IPv6), Internet-Draft, draft-ietf-sipp-icmp-igmp-00.txt, September 1994. Transition Mechanisms R. Gilligan, Simple Internet Transition Overview, Internet-Draft, draft-gilligan-ipv6-sit-overview-01.txt, November 1994. R. Gilligan, E. Nordmark, Transition Mechanisms for IPv6 Hosts and Routers, Internet-Draft, draft-gilligan-ipv6-trans-mech-00.txt, November 1994. D. Haskin, R. Callon, Routing Aspects Of IPv6 Transition, Internet-Draft, draft-haskin-ipv6-routing-aspects-00.txt, November 1994. Security R. Atkinson, IPv6 Security Architecture, Internet-Draft, draft-atkinson-ipng-sec-00.txt, November 1994. R. Atkinson, IPv6 Authentication Header, Internet-Draft, draft-atkinson-ipng-auth-00.txt, November 1994. R. Atkinson, IPv6 Encapsulating Security Payload (ESP), Internet-Draft, draft-atkinson-ipng-esp-00.txt, November 1994. Discovery W. Simpson, IPv6 Neighbor Discovery -- Design Requirements, Internet-Draft, draft-simpson-ipv6-discovery-req-00.txt, September 1994. W. Simpson, IPv6 Neighbor Discovery -- Processing, Internet-Draft, draft-simpson-ipv6-discov-process-01.txt, October 1994. W. Simpson, IPv6 Neighbor Discovery -- ICMP Message Formats, Internet-Draft, draft-simpson-ipv6-discov-formats-01.txt, September 1994. Domain Name System S. Thomson, C. Huitema, DNS Extensions to support IP version 6, Internet-Draft, draft-thomson-ipng-dns-00.txt, October 1994. Auto Configuration D. Katz, IPv6 Address Autoconfiguration Protocol, Message to addrconf@cisco.com mailing list, October 23, 1994. Program Interfaces R. Gilligan, S. Thomson, J. Bound, IPv6 Program Interfaces for BSD Systems, Internet-Draft, draft-gilligan-ipv6-bsd-api-00.txt, October 1994. IPng Overview R. Hinden, IP Next Generation Overview, Internet-Draft, draft-hinden-ipng-overview-00.txt. The following documents were considered to not be part of the core specifications: Header Compression W. Simpson, IPv6 Header Compression, Internet-Draft, draft-simpson-ipv6-hc-00.txt, September 1994. OSI NSAP Mapping B. Carpenter, J. Bound, Recommendations for OSI NSAP usage in IP6, Internet-Draft, draft-carpenter-ip6-nsap-map-00.txt, August 1994. Mobility W. Simpson, IPv6 Mobility Support, Internet-Draft, draft-simpson-ipv6-mobility-00.txt, November 1994. The following documents belong to non-IPng working groups, but still need to be done: Routing G. Malkin, RIP for IPv6, Internet-Draft, draft-ietf-ripv2-ripng-00.txt, November 1994. Y. Rekhter, P. Traina, IDRP for IPv6, Internet-Draft, draft-ietf-idr-idrp-v6-00.txt, November 1994. F. Baker, R. Coltun, OSPF IPv6 Extensions, Internet-Draft, draft-ietf-ospf-ipv6-ext-00.txt, November 1994. Neighbor Discovery The issues from the Wednesday working group session were discussed in more detail. Mobility Extensions: This will be removed per earlier decision. Random (dithering) Solicitation Delay: Group agreed to not delay initial transmission of router solicitation. Cluster bit: Group agreed that each advertised prefix shall have two associated bits, indicating (a) whether or not the prefix may be used to form a self-configured host address, and (b) whether or not the hosts may assume that all destinations with that prefix are directly reachable on the immediate link. If no address-configuration-allowed prefixes are advertised, hosts are expected to use DHCPng to obtain their addresses. Why not use solicitation to form a cache entry?: This generated a long discussion of address resolution issues. Group agreed to keep current approach. Longest match source address (bitwise compare): No agreement. Issue taken off-line. Range of time values: Request had been made for 100 msec. granularity. No room currently for larger values, hence upper limit of 650 seconds. Group decision to increase field size to 32 bits. Redirects: There was a request for a new code value? Group decided to keep as is. Discuss Static Routes: Currently not referenced in sending rules. These need to be reviewed on the list. Packet format/TLV Concern: Proposal to redo the formats of the discovery message to have a fixed header portion with the fields that are required and to only use the extensions for optional fields. There was a weak consensus to further explore issue. Bob Hinden will work with Bill Simpson. Hop Limit Advertisements: Discussions with conclusion that API should allow the default value to be overridden. No change from current specifications. Next Meeting Meeting ended with the announcement of an interim working group meeting, around the first week in February. It will be a two day meeting on the West Coast. [Reporter's Note: The meeting was scheduled for February 9 and 10, at Xerox PARC in Palo Alto, California.]