CURRENT_MEETING_REPORT_ Reported by Ross Callon/Bay Networks Minutes of the IPng Working Group (IPNGWG) The main agenda item was to review the documents which were (hopefully) ready to go to Proposed Standard status. The authors of each document presented the status of the document, and any changes that have been fixed due to the Last Call process. The hope/goal is to prepare these documents to go forward as Proposed Standards immediately following this IETF. After these documents are done, the next ``major piece of work'' is to straighten out mobility for IPv6. This however was not planned for this IETF. There is still some thrashing out to be done by the IESG regarding which group is to complete the work on IPv6 mobility (e.g., the IPv4 mobility group, the IPv6 group, or a new group). Core IPv6 documents to be reviewed/progressed: o IPv6 base specification -- Steve Deering o Addressing architecture -- Bob Hinden o Unicast addressing architecture -- Yakov Rehkter o Unicast addressing format -- Yakov Rehkter o ICMPv6 (including IGMP) -- Alex Conta o Security -- Ran Atkinson o DNS -- Sue Thompson o Neighbor discovery -- Bill Simpson Masataka Ohta requested a discussion of alternative unicast addressing methods. This was added to the agenda. Brian Carpenter raised the issue of the ultimate authority for the IPv6 address space. There is an IAB/IESG draft out suggesting that the ultimate authority for the IPv6 address space rests with the IANA (Internet Assigned Numbers Authority). This was included under the extended addressing discussion. Steve Deering: IPv6 Base Specification Issues brought up as a result of the Last Call include: o How higher levels compute pseudo headers if the jumbogram option is included. This is straightforward and was fixed prior to the IETF. o Destination Options Type that identifies the Destination Options Header was assigned number 60. o The source routing header that was submitted as Last Call included a bit mask. There was a minor error, related to which bit applied to which address in the source route. This again was corrected. o It was proposed to ban the use of the Jumbo Payload option for packets which are smaller than 64k (i.e., which do not require the Jumbo option). Question: How does the group feel about this (clearly either would work)? If we ban the use of Jumbo Payload option for smaller packets, this would allow implementations to not implement this unless they are attached to links which can handle large datagrams. There was consensus on banning the use of the option for small packets. It was agreed to add a note that if you do not implement this option, then you restrict the use of your implementation on links which can handle larger packets. o The recording of the path during forwarding of source routed IP packets has not been carried over to IPv6 (you just swap addresses, leaving the original list of addresses in the packet rather than replacing them with the addresses of the outgong interfaces). One motivation for this is that cluster addresses want to be left alone (you might not go back via the same routers, even if you do go back via the same clusters). This relates to the reversing of source routes. A suggestion is that you do not reverse the source route if there is any route available. The consensus is to leave this as it is in the specification. o The relative ordering of the authentication and fragmentation header: A concern is that if you first reassemble and then authenticate, then bogus fragments can break the whole packet (representing a denial of service attack). However, if you authenticate fragments, then bogus fragments are discarded, and the correct fragments can be reassembled (with more overhead). The current approach allows either order, but recommends authenticating the entire packet (not each fragment). However, authenticating the entire packet (rather than each fragment) implies substantially less overhead. Consensus: The specification is already clear that implementations must be able to receive packets in either order. The current order is fine in terms of what is recommended to be sent. Thus no change is necessary. o In the introduction of the specification there is a reference to the ``region address.'' This needs to be either removed or changed to ``Anycast address.'' The one corresponding sentence needs to be fixed. Author's choice regarding how to fix this (this is an editorial nit). o ERP (Explicit Routing Header): This is not currently in the base specification in detail. The Route header in the base specification will remain compatible with the current state of Explicit Routing Header format, by reserving the space but not defining the flag fields. The proposal is that this is not ready to be added, and therefore should not be added to the base specification. Consensus is to leave the specification the way that it is. o Privacy header: Why isn't the code point in the IPv6 protocol specification? This is largely a style issue (given that the privacy header is specified in one of the base documents which will go to Proposed Standard). Bill Simpson proposed removing the authentication header from this specification also, and have all security, authentication, and privacy stuff in other specifications. The consensus was to delete the authentication header section in the IPv6 protocol specification, except to include mention of authentication and ESP headers in the order of headers section. It was also agreed to have a small section listing all the existing header types, but referring for code points back to assigned numbers. Bob Hinden: Addressing Architecture Output of the PARC meeting was listed as document version -01. However version -02 just came out since based on comments received, but did not quite get to Internet-Draft (came out at the last minute). Bob therefore described the delta between the -01 (just after PARC interim meeting) and the -02 version. o Loopback address: An explicit note will be added that a packet addressed to the loopback address is never sent out of a single node. What it means to be a ``node'' or ``device'' is up to the implementor of the node/device. o The definition of the term ``nearest'' is somewhat unknown. The notion is that this is ``according to the routing protocol's measure of distance.'' The word ``nearest'' will be surrounded by quotes in the specification, as a minor clarification. o The scopes for multicast addresses was discussed. It was agreed to remove the notion of a ``community'' scope. o Directed multicast (i.e., a multicast as the last entry of a source route): This is dis-allowed intentionally in the specification. This is a problem due to the fact that the directed multicast would have the wrong source address to work correctly with current multicast routing protocols. Thus the current text is correct. A different (future) mechanism would be needed for directed multicast. o Will local use prefixes need to be predefined? Yes, Bob will add this to the document. o Question: What about clusters, packs, anycast, etc. (whatever it is called this week)? Anycast goes to the nearest (or some one) of a group. Cluster is a special constrained form of anycast, applied to any address prefix. There was a problem with cluster addresses related to how a cluster address was identified. The Pack proposal was to generalize how a particular address was chosen to be the pack address corresponding to a particular prefix, plus some generalization of topological restriction. The name was changed to region, and folks noticed that the definition of regional addresses had been generalized to be nothing more than a renamed anycast address (perhaps made more complex). Thus, we now have returned to just having Anycast addresses. Any unicast address can be assigned to more than one machine, which causes it to become an anycast address. Any machine to which an anycast address has been assigned must know that this is an anycast address. There is a proposal to assign a particular anycast address to the set of all routers on any subnet. Bob will add a clarification of the anycast addresses to the current document. There followed a lengthy discussion of a possible multicast address space proposed by Masataka Ohta. It was agreed that this was an interesting proposal that is worth discussing and considering in the future, but that we will not be able to resolve the scheme and understand its implications in this meeting, and therefore should go forward with the base specification as it currently stands. We would like Mr Ohta's proposal to be written up in more detail and distributed prior to the next IETF (clearly it is beneficial to have an Internet-Draft early enough to allow considerable discussion and comments prior to any particular IETF). It was agreed to progress the first two documents (IPv6 base specification, IPv6 addressing architecture). Therefore, a discussion was started of the provider based addressing specifications (the two documents by Yakov Rehkter). There was considerable discussion pro and con. This was partially based on whether people like provider based addresses. Some opinions ranged from ``provider based addressing is the best that we know how to do'' to ``provider based addresses are not ideal in many ways.'' In addition, if we are going to do provider based addresses, there may be ways to simplify the associated issue with address changes, for example when a corporation changes its provider. The continuation of this discussion was postponed to later. Alex Conta: ICMPng (Including IGMP) There were several typos and spelling errors corrected. References to ICMP were replaced with ICMPv6 (different protocol value). Section 2, introductory section entitled ICMP for IPv6, was divided into several subsections: o message general format o message source address determination o message checksum calculation o message processing runed TBD fields were replaced with the ICMPv6 next header value (58). Source address determination was clarified in the case of error reports sent in response to a packet with an anycast destination address. Also in the case of ``destination unreachable -- communication administratively prohibited'' or ``destination unreachable -- address unreachable,'' and ``Address Too Big.'' There was some concern that this is somewhat complex, and/or not so clear. The consensus is that we will add a sentence saying essentially ``use the address which returns the most information,'' then say ``for example...'' and include the current text with ``should'' instead of ``must.'' Fields used in the checksum computation have been clarified in the case of a Jumbogram. (question, would there ever be an ICMP jumbogram -- yes, if it were a ping; thus it is worth specifying what to do in this case). The handling of unknown error messages was separated from the handling of unknown informational messages. Similarly, references to ICMP messages in general was clarified to separate error and informational messages. Some minor editorial corrections were discussed. An error message was added for the case of strict source routing when the next hop is not a neighbor. Source address determination was clarified for time exceeded message. The pointer for use in parameter problem message was also clarified. The consensus was that ICMP is ready to go to Proposed Standard. DNS (AAAA Records): Sue Thompson Bill Fink was proposing to split the addresses into two pieces: A provider part plus a local part. Then if you change providers, you change the higher level part only. Question: Why not just assign addresses this way: So that when you change only the provider part, you only change one entry in DNS, not all addresses for one domain. However, this seems to be a research topic. Bill Simpson thinks that we have discussed this for a long time, and he does not want to get back to it now. Consensus: The DNS for IPv6 document is ready to go to Proposed Standard, and represents the state of the art. Additional work may go on as experimental. The earlier discussion at the Palo Alto interim meeting and on the mailing list about replacing the reverse tree lookup was not extended by the working group. The working group decided that the current text on reverse tree was acceptable for elevation of the specification to Proposed Standard, and that future design of secure, less cumbersome approaches would not be precluded by starting from this point. Bill Simpson: Neighbor Discovery A significant issue here is the handling of the node heard mechanism. It has been suggested that there is not enough explanation in the neighbor discovery specification regarding why the document is written the way that it is. When router discovery was being defined, they went through existing protocols and decided what they liked, what they did not like, and what they were trying to solve. They wanted neighbor discovery to work for a wide range of types of networks. A lot of thought has gone into Neighbor discovery for Non-Broadcast Multi Access media (NBMA). Here you cannot necessarily hear folks who can hear you. Also, neighbor discovery needs to work in a no-router environment, and in via-a-router-when-necessary environment. Neighbor discovery specifies: o The manner for a node to solicit another node (using a certain multicast address hashed from IPv6 address) o The manner for a node to answer another node (using all nodes multicast) The neighbor discovery messages include an indication of link quality. It was agreed that a link quality value needs to be defined for the case when the interface is not able to measure the link quality (the node can specify a zero error rate, the link quality is then assumed to be good). Suggestion: Allow solicitation to be unicast if the address is known. Also, allow response to also be sent using unicast. Issue: If overhearing the other guys messages is a substantial advantage, then the node heard field is useless. Brian Carpenter stated that the assumption of multicast/broadcast in the NBMA case is dubious. A different model may be necessary in some cases (e.g., compare RFC 1577 for ATM). Several comments were made regarding whether node heard should be in the packet. Some folks would like to remove node heard. If there is a problem, that you might have heard from too many folks implying too long a list, you could put an indicator which says ``lots of folks'' in the packet without being specific (however, the note taker thinks that Bill Simpson explained that you will never have such a long list in the ``node heard'' field -- there was some misunderstanding in the room on this issue). In the general case (where subnet does not provide cheap multicast) when a router is there, (suppose node A is attempting to contact node B): A just sends data to a router. The router then looks for B (The apparent notion is that routers have to find the hosts anyway). However, in sending the solicitation the router semi-lies, using its own link address along with host A's IPv6 address in the solicitation. B responds with a response sent to the all nodes multicast address, which should imply that A will receive it. It was suggested that non-transitive or non-reflexive failures can also happen (with significant frequency) on Ethernet. A proposal was made that node-heard should be in a separate document (which might not apply to all types of links). The term ``Asymmetric reachability'' as used includes error cases: ``A can hear B but B can't hear A,'' and ``A can hear B and B can hear C but A can't hear C.'' Bill is assuming that ATM will solve the multicast/broadcast issue (i.e., allow efficient multicast over ATM). However, it appears to the note taker that if ATM does not come up with a multicast that one would actually want to use in this case, then an alternative approach may be necessary. Further discussion of neighbor discovery was deferred to later in the week. IPv6 Security: Ran Atkinson Delta's since last time: o Merged IPv6 and IPv4 work since differences were minor. o Moved next header field to the end of the encrypted data. o Someone came up with a transform that preserves 64-bit alignment. o Changed the way the MD-5 hash was computed. o Moved transforms into separate, more clearly-written drafts. Jim Bound has a major objection to having this go forward as a Proposed Standard. His issue is that security being a must forces him to build a non-exportable product. There is some question as to whether DES is really exportable (with a license) or not. There appears to be some strong feeling that security is needed, and that exportability is needed. After some discussion, it was agreed: o From a technical perspective, security including privacy must be implemented, and is needed for Internet commerce to work. o Some users from outside the US have expressed an interest in purchasing systems which include security. Neighbor Discovery and Addressing Masataka Ohta presented his reason for being opposed to progression of the two provider-based addressing documents (by Yakov Rehkter). He is against progressing the existing documents on provider based addressing to Proposed Standard because the approach contains known problems. This will lead to a compatibility problem when we have to change addresses in the future. Also using part of the address space for provider based addresses is a potential waste of space if we assign a significant part of the addressing space to addresses which will become obsolete. Ohta presented some aspects of his proposal. His proposal is based on provider based addressing, but with mechanisms to deal with change of providers. However, we did not have time to discuss the proposal in detail. In response to Ohta's proposal, Matt Crawford pointed out that the entire address guarantees global uniqueness, not just the low order part. Also, 46 bits (the useful part of the IEEE space) is much larger than 1012 (the anticipated eventual size of the Internet). Brian Carpenter, and then the group as a whole, agreed with Ohta's suggestion to do initial assignment conservatively, to preserve as much as possible of even the provider-based IPv6 space. There are two places where this should be done: Assignments of prefixes to providers, and assignments from providers to sites. There was strong agreement that we need to continue addressing work. The provider-based documents that Yakov has written are not the end point. Bill Simpson is opposed to publishing the provider based addressing documents as Proposed Standards. He feels that architecture draft is incorrect. He does not feel that there are multiple interoperable implementations. He questioned whether we need address assignment for initial experimentation with IPv6. Rather, we should plan on telling folks that they are going to have to renumber in order to do initial experimentation with IPv6. Roger Fajman from the National Institute of Health was concerned about renumbering. For example, this could happen if your connection is moved within a provider. Renumbering is going to be hard in spite of our efforts. Support for renumbering needs to be in place before the wide deployment of IPv6. There are really four issues: Addressing; multiple addresses for an interface (multi-homed addresses); how is local portion of address assigned; how does all this work with DHCP. A proposal was made that the addressing document should really be a request for comments (as opposed to an ``RFC,'' which is of course often interpreted as a ``standard''). Ross was concerned that we have not heard any new arguments for a year plus. In the Internet tradition, when we do not have a perfect solution and we are not making progress, we have to go with the best that we have (regardless of however imperfect that may be). We will then learn from our experience. An informal show of hands regarding whether the architecture draft should be published as an RFC in some form: Yes, by about 3 to 1, with a lot of abstentions. Informational was the rough consensus regarding which form the document should take. Same informal show of hands regarding the address assignments: There has already been a rough consensus on adding text regarding conservative assignment. Overwhelming support for publishing in some form. Also consensus that it should be Informational. We then continued with neighbor discovery: Several folks had questions regarding detailed operation, and presented detailed examples so that Bill Simpson could explain the protocol operation. Erik Nordmark brought up an example with two routers (R1 and R2) and two hosts (A and B). A can hear R1, but R1 cannot hear A (i.e., there is an error in the network, the type of error that node heard is intended to fix). A and R2 can hear each other correctly. Erik's interpretation of the specification is that A will end up picking one of the two routers according to a criteria, and may pick R1. However, when A tries to send the packet to R1, it does not arrive. How does node heard fix this problem? Bill's response: this has nothing to do with node heard, and node heard is not supposed to fix this. If R1 has a higher preference than R2, this just will not work. This lead to the counter-question: What does node heard do then? (Apparently it is useful in the host-to-host case.) There seemed to be a significant amount of discomfort and lack of understanding of the approach (including among some implementors who had read the specification), which is clearly different from there being known problems. There were some folks who feel that this is no worse than, and probably an improvement over, what we have now (ARP). Matt Crawford suggested that we might need ``router discovery light'' and ``router discovery dark.'' John V. was hearing that this is a complicated problem, that is not fully understood and not fully explained in the current document. Some implementors in this room are saying that they are not comfortable. We need to either strip this protocol down to something better understood, or make it (whether the description or the protocol) more complete. The area director suggested that we need a well understood protocol which does the equivalent of both ARP and Router Discovery for networks which do not need to survive asymmetric reachability. Ross suggested that if we are uncertain about the node heard mechanism, then the specification should be very clear about what an implementation should do if it expects the field and it is missing, or vice versa (so that we have the option of changing the mechanism in the future). Steve would prefer a small set of protocols for a small set of overall basic network types (i.e., not just one mechanism for all links, but not a separate mechanism for every single type of subnetwork either). Bill Simpson agreed to excise node heard, and questioned how much that will simplify things. There appear to be two issues: Clarity of document, and correctness of (or comfort with) the technical approach. The group expressed (by show of hands) a mild preference for taking node heard out of the document, and putting into another document. We have not reached a consensus. Bill will revise the document. We will put it out for working group last call. Bill will not put it out for three weeks. The working group's official editor (Bob Hinden) offered to make an effort to edit the document for completeness and clarity. It was left somewhat unclear how Bob and Bill would interact on this (although presumably they can work this out off-line). We may need an interim meeting: This will be arranged off-line.