Editor's note: These minutes have not been edited. Date: Wed, 18 Oct 1995 12:12:12 -0700 From: "Robert M. Hinden" IPng/AddrConf Working Groups Interim Meeting October 11 & 12 1995 Dyncorp, Arlington, VA Minutes produced by Robert Hinden / Ipsilon Networks -------------------------------------- Attendees: Steve Deering / Xerox PARC Robert Hinden / Ipsilon Thomas Narten / IBM Erik Nordmark / Sun Alex Conta / Digital Dan McDonald / NRL Tim Hartnick / Mentat Gaetan Feige / ISI Bob Gilligan / Sun Scott Behnke / Dyncorp Richard Colella / NIST Steve Silverman / BTNA Rob Glenn / NIST Peter Grehan / Ipsilon Sue Thompson / Bellcore Jim Bound / Digital Dan Harrington / Digital Allison Mankin / ISI Matt Thomas / Digital -------------------------------------- Agenda o Administrivia Introductions Note Taker Chairship videotaping Document Status o IPv6 Payload Header o AddrConf Discussion of Latest Specifications o Neighbor Discovery o IP over Foo Documents o "IGMP" for link local multicasts -------------------------------------------------------------------- Wednesday, October 11, 1995 -------------------------------------------------------------------- The meeting was hosted by Scott Behnke / Dyncorp and Allison Mankin / ISI. Robert Hinden agreed to take notes for the meeting. Steve Deering announced that Ross Callon was stepping down and Robert Hinden will be the new co-chair (and continue to be document editor). Steve Deering reviewed standards status. Base specification, address architecture, ICMP, and DNS specifications were approved by IESG to be Proposed Standards. Provider assignment architecture was approved for informational. All are being submitted to RFC editor to become RFC's. IETF last call being done for NSAP doc. Working group last call completed for Provider Formats and Test Allocations addressing drafts. No comments on Test Alloc. Only discussion on Provider Based was if it should be Informational, BCP, or PS. This Issue was discussed. Group agreed that Provider doc should be advanced as a Proposed Standard. Chairs will send note to IESG requesting these docs be advanced w/ cc to working group. ---------------------------------------------------------------------- IPv6 Payload Header ---------------------------------------------------------------------- Discussion on "The IPv6 Payload Header" draft. It would be used to identify how multiple headers (e.g., more than one TCP header) could be combined in one IPv6 packet. Issue raised that might be hard to implement if several non-related headers were included. It would have to be required to be implemented by everyone to be useful. Discussion of benefits and costs. There does not appear to be any commercial implementations of TMUX (somewhat similar for IPv4). There does not be enough support in w.g. to advance this to the IESG at this time. Members of working group should review this document and comment if there is interest. At this time there is not enough motivation to require this to be required for universal implementation. Suggestion also made for some implementation experience before considering this for advancement to become a standard. Most people have not read the draft, not much interest, author will have to make a better case. ---------------------------------------------------------------------- Addr Conf ---------------------------------------------------------------------- Sue Thomson / Thomas Narten (gave presentation) Open Issues: o Duplicate address detection o Loop back semantics o Changing "AutoConfig" flag on running systems o Terminology for MAC address o Node vs. Router o Configurability of "DuplAddrDetect" o Separate ICMP Message for AddrConf and ND ------- Strength of Duplicate address detection Discussion of sending out single packet or retransmission. Most people thought only single NS was enough. It would be nice to not delay booting waiting for an answer. Current implementations of duplicate detection in IPv4 (using ARP) do not wait. However, if duplicate addresses are present, immediate use causes problems for existing interfaces using the same address. Waiting for DAD to complete avoids this problem. Suggestion for different modes of operation depending on type of address (autoconfigured addresses, dynamically assigned, manually assigned). Suggestion for sending one NS packet, waiting a short period of time (one second) for duplicate. Pick generic default for Addrconf and allow specific IPoverFoo documents to set new default value for a particular media. Group agreed that default behavior should be to send single NS packet, and wait for 1 second to detect duplicates, and that these values be configurable. A specific IPoverFoo document could define a link specific value to change default values. The number of retransmissions is also link type specific. [See later discussion] Discussion of how much random delay before sending NS. The current value is 3 sec, which is larger than the random delay used before sending out a RS in ND. One of the differences is that all nodes will send an NS, whereas nodes will desist from sending an RS on hearing a RA. ------- Discussion of whether hosts can do duplicate detection and router discovery in parallel (or does it have to be sequential). Parallel is preferred, since it reduces time before normal operation can start, but requires that RAs are solicited using the unspecified address and that RAs are multicast. [See later discussion] -------- Configurability of Duplicate Address Detection Flag Currently per interface configuration flag. Change text to require duplicate detection of link local address. Other addresses derived using this, do not need to be checked for duplicates. (This avoids the problem in stateless autoconfiguration of having different interfaces choose different addresses to apply duplicate address detection to.) Duplicate detection required for all stateful and manually configured addresses. Instead of having this flag, there are now two per interface variables to do with duplicate address detection. First variable indicates how many times a solicitation is sent for duplicate detection. Second is timer value for interval between retransmissions. Default values are 1 transmission, and 1 second. Duplicate address detection is disabled by setting first value to zero. Hence, no need for separate "Duplicate address detection flag" -------- Semantics of Multicast loopback The current text looks OK. One further thing to consider though. Loopback is undesirable for general multicast applications. Thus, IPv4 multicast specification requires that driver suppress loopback. If not possible to disable hardware, driver software needs to filter out loopback multicast packets. If this filtering is done by comparing the source address of the packet with that of the interface, i.e. dropping packets whose link-layer source address is the same as that of the interface, then this breaks DAD in the case where duplicate addresses result from duplicate interface tokens (e.g., two interfaces both using the same link-layer address). Prefer interface to not loopback multicast packets. Approach should be to configure hardware to not loopback, or have driver (in software) detect duplicates with a mechanisms other than looking at the source address. If the two previous are not possible, then a trade-off needs to be made: allow loopback (allows duplicate address detection to work, but inefficient in terms of multicast interrupts) or suppress loopback by comparing source address of incoming packet and interface (reduces number of interrupts, but disables duplicate address detection). It is possible that an implementation might make loopback suppression configurable in this case, i.e. only turn it on when duplicate address detection done. Agreed that text will be added to document explaining the problem, but leave as an implementation issue how resolved. ---------- "AutoConfig" Flag What happens if flag turned off and on in running system? Should addresses from previous incarnations be kept until they time out, or should address list be reinitialized each time flag turned on? Discussion leading to conclusion that this should be an implementation issue. Discussion of what "AutoConfig" flags means. First, should the flag apply to formation of the link-local address? There was agreement that it should not. That is, the link-local address is always formed. The implication of this decision is that there needs to be a way for the token to be configurable, in the (rare) case, when the token is found not to be unique. Suggestion for advice in IPoverFoo specs for what to do if duplicate is detected. Second, what part of Router Advertisements should the "AutoConfig" flag apply to, just stateless auto-generation of global or site-local addresses or all autoconfiguration information in router advertisements? What does flag say about using stateful mechanism in absence of RAs? One suggestion was that the "AutoConfig" Flag should only refer to the automatic creation of addresses and bit flags telling hosts to use DHCP (e.g., ignore this information in router advertisements). Other functions not affected (e.g., duplicate detection, link local, router discovery, routing prefixes, etc.) Another suggestion was for two independent flags, one for disabling stateless and one for disabling stateful autoconfiguration. On working through these options, it became clear that there were several ways of defining the semantics, and that the spec need not mandate any one way. Thus, the conclusion was to not specify specific variables, but just for the spec to say that it should be locally possible to disable all autoconfiguration functions, and that the functions must be enabled by default. ----------- Node vs. Router What part of the functions in the document should apply to routers? The conclusion was that routers are outside the scope of the document, with the exception of formation of the link-local address and duplicate address detection, which apply to all IPv6 nodes. Discussion about whether the addr conf doc should describe how addresses are created, or whether it should be in the IPoverFoo documents. The latter might require IPv6 code to know about different mechanisms to create address for each IPoverFoo type. After discussion, group agreed that IPoverFoo specs need to specify the rules for handling the bits in the address token and the AddrConf spec should describe putting the prefix and token together. Steve Deering suggested: Define interface tokens as bit strings. AddrConf spec defines how to append bit strings with prefix to form an address. IPoverFoo specs specify how to create a bit string and may give an example of what a link local address looks like for this media (to avoid confusion about bit orderings). Prefix + address token must equal 128 bits. Router is required to advertise prefixes which when combined with the token for that particular interface type add up to 128 bits. Zero padding not allowed, since padding rules may be link-specific. --------- Terminology for MAC/Hardware address Should be "Link-Layer Address" ----------- Terminology Current spec uses the following terminology: Preferred Address Deprecated Address Preferred Lifetime Time-till-deprecation Valid Lifetime Time-till-invalidation Group agreed these terms were OK. -------- Discussion about whether document applies to point-to-point links, tunnels and NBMA networks. Specification will be updated to clarify that this specs requires the use of multicast on networks. This does not mean to say, however, that parts of the spec, e.g. formation of link-local address, may not apply to non-multicast capable networks. -------- Separate ICMP Messages for Addrconf and ND Jim Bound requested that different ICMP messages be used for addr conf and ND. He wants different machines to be able to send each type of message. Doesn't like the "extra" complexity of receiving combined information. However, it was not clear how the information should be divided up, e.g. separation of prefix advertisements from other information advertised by routers, or separation of address-related information (and possibly other configuration parameters) from router advertisements, etc. Group conclusion was to not divide this information into separate ICMP messages. ------ [Non- addrconf related item] The ICMP redirect will be given a code out of the informational instead of the error cases. Code will be 137. ------ Group agreed that with the changes/clarifications made in this meeting, addr conf (once revised) can go forward to Proposed Standard. ---------------------------------------------------------------------- Neighbor Discovery ---------------------------------------------------------------------- Erik Nordmark (presenting) & Thomas Narten Outstanding Issues: o Messages from off link sources o Extra NUD probes for unsolicited information o IPv6 Priority field in ND packets o Randomizing Reachable Time o RS with unspecified source o Retransmission Timer = 10 sec. o Preferences for Default Routers o Prefix Redirects (instead of just host redirect) o Reachable Confirmation / Negative vs. positive & Implementation Issues o Implementation Language o MTU Advertisements (per receiver MTU's) ----- Messages from off link sources Don't want to have to deal with messages which might have leaked in from outside of the local link. Issue is malicious attach from off link. Long discussion. Suggestion to always do NUD using link-local address. All advertisements would include both global and link-local address. Suggested alternatives (to solve the off net problem) are hoplimit=0 and/or "don't forward" IPv6 option. "router process" with proper semantics would help other (somewhat related) problems. This plus a flag could tell routers to drop these packets. [See later discussion about hoplimits] Much more additional discussion. Possible solutions to multiple NUD probes are: 1) carry link-local in all packets 2) zero element source route. Discussion about not using link-local address as source of this packet because it also causes an 8 packet NUD exchange. General consensus that we should use a "do not forward" hop-by-hop option and use global source address instead of link-local address. Recipient checks if "do-not-forward" option present. This seems to deal with off net attacks (either router drops or destination drops) and stops 8 packet NUD exchange (back to four packets with special rules or other mechanisms). Possible choices are: o Carry Link local in all ND messages o Do nothing to special to defend against off net attacks o Don't forward option o Keep current spec operation of saying to not do NUD for ND packets. Queried everyone in room to gauge consensus. Result was: Four said they liked "don't forward" option Eight said they liked keep current spec One for "Alert" option to require router to do full processing More discussion. Will revisit on second day of meeting after Erik Nordmark and Thomas Narten present summary of changes required to ND for making "don't forward" change. ------------ IPv6 Priority in ND Packets Suggestion is to make ND packets high priority (over video and audio). Proposal is to set it to 15 (highest value). --------------- Randomizing Reachable Time Time to send next probe. Each time need to send Range 0.5 - 1.5 (x 30 seconds) Use this unless get new value from router advertisements. Concern is for nets without routers, will always use same value. Could recompute when going into PROBE state. Issue is how often should we recompute the random number. Current specification says recompute when new RA is received. However, if no RAs are present, computing the value once at boot time and then never again results in some machines having a short (15 second) ReachableTime, while other machines use long (45 second) time. Recomputing each time the timer is set (e.g., whenever going into a REACHABLE state) seems excessive. Proposal to change computed random value once a day or if hear new router advertisement. Group thought this was a good idea and adopted it. Randomize: New value in Router Advertisement occasionally receive RA / once an hour ---------------- RS with unspecified source Needed to make initial ND startup parallel with AddrConf. Relates to Nordmark/Narten homework assignment. [See additional discussion] ------- Extra NUD Probes for Unsolicited Information Propose to introduce STALE state. First packet in STALE => PROBE. PROBE delays for N seconds until sending NS. Group decided to adopt this proposal. --------- Retransmission Timer = 10 sec. This is the timer used for retransmitting neighbor solicitations when node doesn't have a address or for reachability when no routers are present. Suggestion that the default for each link type should be specified in the IPoverFoo specs. Group decided to Change default timer value to one (1) second. IPoverFoo spec can define link type specific default. Value in router advertisement will override. We can now use this timer for duplicate address detection. ------ Prefix Redirect Proposal for Prefix Redirects. This would allow less redirects for traffic to same destination (and destinations in same prefix). Problem what to do when NUD detects neighbor router is down. Does it invalidate all routes in that prefix? No clear answer to do this. Group will continue discussion on second day of meeting. It was also noted that prefix redirects could be added in a backwards compatible manner (using part of the reserved field in the redirect message to specify the prefix length) should the need be stronger in the future. -------------------------------------------------------------------- Thursday, October 12, 1995 -------------------------------------------------------------------- (continuation of Prefix Redirects discussion) Prefix redirect would result in the addition to the redirect message a length of the prefix which the redirect covers (current redirect is host style redirect). The prefix redirect could be disabled by setting the prefix length to 128. Hosts could either do full longest match routing or still deal with this on a per connection basis (e.g., host route). Discussion if people thought that routers would really implement this. Discussion about how host and routers would deal with receiving variable length prefix redirects. Continued discussion about merits, usage, etc. Not clear if benefits out weigh the complexity of specifying how a host needs to deal with longest match routing. After polling the group there was a consensus to not adding Prefix Redirects to ND. ---------- MTU Advertisements Proposal for hosts to be able to advertise individual MTU values. Would allow a host to have a specific MTU for it. After discussion which pointed out the per-host MTU (or MRU) do not work with multicast the group decided not to do per-host MTU advertisements. ------------- Benefits of "Don't Forward" Option (homework from previous day) o Remove ICMP Sender address field from NS. Results in simplified processing. o Remove "no NUD for ND Packets" o NS and NA use global source and destination addresses. o Allow link-layer address option on all packets (except unspecified source) o Remove validation checks on source and destination o Remove "no source router header" validation check Note: Host<-->Router control messages (RA, redirects, etc.) will still use link local addresses. This still permits hosts to maintain their router associations in the event of renumbering. document authors recommend that this change be made. Bob Gilligan made proposal that instead of Hoplimit=0 or "don't forward option", could use HopLimit=255 (max value). Host would only accept packet if HopLimit=255 when received (e.g., it had not been forwarded). No special processing required in routers. This would be used for all ND messages. No "don't forward option" and no HopLimit=0. Group agreed to adopt these changes. ------------ Discussion about how negative advice from TCP could be use to trigger ND. This would only be useful for on link destinations. Additional discussion about how to use positive information from TCP. When receiving an ACK which advances TCP window, this can be used to provide positive notification that there is positive confirmation of reachability. This can be used to update ND's state and keep NUD messages from being sent. No change to the ND specification, but this is good advice to Implementors. --------- Implementations language discussion will be taken off line with document authors. -------- Preferences There are currently no preferences in IPv6 router advertisements. There are preferences in IPv4. There has been a request on the mailing list that IPv6 also have preferences. Desire for a subset of routers on a link to be given "default" status and others to not become default routers. Discussion of pseudorouters (e.g., routers with less than full functionality) and that these type of routers might work better if there were router preferences. Not clear if the IPng specifications should have to specify what minimum functionality that a node needs to implement. There are too many different cases of nodes which do not do the full functionality to try to define what all of the interactions and combinations are. Do the IPv4 semantics satisfy the request or do they need to be more sophisticated? --- Thomas Narten presentation on this topic. Current ND draft assume routers are "smart" and send redirects o In IPv4 reality doesn't match this ideal fix in IPV6? o Routers send redirects based on their own view of the topology rather than originating hosts view. +--+ +---+ +---+ | |---R2--| | | | H2--| | | |--R1--| |----H1 | |---R2--| | | | +--+ +---+ +---+ R3 is "good" router R2 is "bad" router Ideally o R2 forwarding table needs to keep more information; routing operation must be keyed on (arriving interface, destination) rather than just destination. o Router must build separate routing tables for each arriving interface / more computation Does R2 have sufficient knowledge to put itself in "H2's shoes"? o Manually entered routers require additional arguments / flags. o If RIP is in use: - if neighbor router adjust metrics so R2 + R3 are equivalent from H2's perspective. - if R2 adds 1 to each interface metric, R3 becomes better from H2's perspective. ----- Router advertisements w/ preferences does not eliminate requirement for "interface-specific redirect sending" R1-----XXXXXXXX-----H1 / | / | H2 -- XXXXXX R3 \ | \ | R2----XXXXXXXXX------H3 o R1 + R2 have equivalent preferences o H2 using R2 as current default o H2 sends data to H1 o From R2's perspective H1 is one hop away via either R1 or R3 so it chooses R3 o From H2's perspective, R1 is clearly better o R2 should send different redirect to H2 + H2 (e.g., arriving interface specific) -------- What is the big deal about preferences o Inherent conflict between preferences for "default router" vs. router to individual destination. o Which router is best for destination x or default changes dynamically o Routers have this information first, issue is how to best to communicate that information to hosts o Possibilities: + Host wait for routers to tell them everything - Redirect architecture achieves this - Least complex host implementation, - NUD handles black holes + Hosts using defaults routes can easily switch to new default. - Implementation can only use a single router & and does not load balance among equal preference routers o Still need mechanism to probe highest preference router, if it fails. Note: Latter case requires redirects to be timed out. This results in more redirects when nothing is changing. ---- Steve Deering showed a slide showing that preferences do not always result in fewer packets. Sometimes preference result in more redirect packets, sometimes not. H2 H3 | | #####N2#### ###N3####### | \ / | | \ / | | \ / | | R1 | R2 | R3 | | | | | | ########N1######################## | H1 For traffic from H1 to H3 where R1 is best router for destinations on N2 and N3 With no router preferences: If R1 goes down, 50% of the time H1 will pick R3 as default resulting in no redirect when it initiates a connection to H3. The other 50% of the time a redirect will result. With router preferences of R1 being the highest, R2 next highest, and R3 the lowest: If R1 goes down, H1 will always pick R2 as default. This will result in a redirect being sent every time H1 initiates a connection to H3. It is not possible to set up the router preferences in manner which results in less redirect traffic. ---- Narten: Routers learned via redirects become stale o Easiest is simply timeout redirects every N seconds o # of redirects increase o Does not eliminate the need for routers to do route calculations based on source. o Preference potentially reduces the need for above but does not eliminate the need completely. Long discussion about merits and issues regarding adding router preferences. ------ Chair polled room on desire for router preferences: Y= want them, N= do not think should be added N N N N N N N N N N N (there were four non-votes) Deering proposes we do not add preferences, do working group last call, if intensity of debate high is enough from the last call, we will not forward to IESG and continue discussion at the Dallas IETF meeting in December. The group accepted Deering's proposal. ---- Discussion about the need for preferences in anycast address NA's. Anycast addresses were intended to denote "a router" rather than "the best router". In particular, the routing subsystem delivers a packet to "to a router" rather than "the best router". Thus associating preferences with anycast addresses was not really appropriate. After discussing the issues, group decided to not add any preferences for anycast addresses in NA. ------ Erik Nordmark presented analysis on Boot Timing with current ND default timer values. Host: DAD: Random [0-1] second delay Send 1 NS, wait for 1 second RS: Random [0-1] second delay Send up to 3 RS separated by 3 seconds Router: Receive RS Start random timer [0-6] seconds Timer: if received more than one RS while waiting Send RA multicast, else unicast RA. It should be possible to send DAD and RS at the same time, to eliminate the second random [0-1] delay. After much discussion group decided to change so Router will respond with multicast RA (wait random [0-.5 second) and not send another RA for 3 seconds (independent of number of RS received in interval). Routers will always multicast the RA in response to an RS. This should result in faster response to RS and fewer RA on link. Router procedure becomes: Receive RS If have not sent RA within 3 seconds Start Random timer [0-.5] seconds Send RA multicast else wait until (3 seconds + Random [0 - .5)) timer expires Send RA multicast endif ---------- Document Organization Desire to restructure document to move packet formats to beginning of document (after overview), use standard internet bit order, make implementation details generic if appropriate, and other similar formatting changes. Add statement that the protocol is the packet formats and external behavior on the wire and the implementation guidelines are a conceptual model. The protocol is what is being standardized. Implementations are not required to implement guidelines exactly as described. ------ Group agreed that once these changes are made we can do a working group last call. Authors will have a new draft within 3 weeks. ---------------------------------------------------------------------- Minimum Reassemble Size ---------------------------------------------------------------------- RFC of IPv6 will say that minimum reassembly size is 1500 bytes. ---------------------------------------------------------------------- "IGMP" for Link-Local Multicast Groups ---------------------------------------------------------------------- Do membership reports need to be done for link-local multicast groups? It is not clear if required link-local multicast addresses need to be added to IGMP group requests. Could only use for groups which are created by the hosts and not for the required multicast group addresses. Having them in the group would make it easier to prune traffic to groups which do not have any members. Group decided to not include pre-defined link-local multicast addresses in IGMP group messages but will send IGMP reports for other link-local multicast addresses. ---------------------------------------------------------------------- Thanks to Scott Behnke / Dyncorp and Allison Mankin / ISI for hosting the meeting. Meeting adjoined! ----------------------------------------------------------------------