home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ipngwg / ipngwg-addrconf-minutes-95oct.txt < prev    next >
Text File  |  1995-10-24  |  31KB  |  887 lines
  1. Editor's note:  These minutes have not been edited.
  2.  
  3. Date: Wed, 18 Oct 1995 12:12:12 -0700
  4. From: "Robert M. Hinden" <hinden@walnut.ipsilon.com>
  5.  
  6.  
  7. IPng/AddrConf Working Groups Interim Meeting
  8. October 11 & 12 1995
  9.  
  10. Dyncorp, Arlington, VA
  11.  
  12. Minutes produced by Robert Hinden / Ipsilon Networks
  13.  
  14. --------------------------------------
  15.  
  16. Attendees:
  17.  
  18.    Steve Deering / Xerox PARC
  19.    Robert Hinden / Ipsilon
  20.    Thomas Narten / IBM
  21.    Erik Nordmark / Sun
  22.    Alex Conta / Digital
  23.    Dan McDonald / NRL
  24.    Tim Hartnick / Mentat
  25.    Gaetan Feige / ISI
  26.    Bob Gilligan / Sun
  27.    Scott Behnke / Dyncorp
  28.    Richard Colella / NIST
  29.    Steve Silverman / BTNA
  30.    Rob Glenn / NIST
  31.    Peter Grehan / Ipsilon
  32.    Sue Thompson / Bellcore
  33.    Jim Bound / Digital
  34.    Dan Harrington / Digital
  35.    Allison Mankin / ISI
  36.    Matt Thomas / Digital
  37.  
  38. --------------------------------------
  39.  
  40. Agenda
  41.  
  42.   o Administrivia
  43.      Introductions
  44.      Note Taker
  45.      Chairship
  46.      videotaping
  47.      Document Status
  48.  
  49.   o IPv6 Payload Header
  50.  
  51.   o AddrConf
  52.       Discussion of Latest Specifications
  53.  
  54.   o Neighbor Discovery
  55.  
  56.   o IP over Foo Documents
  57.  
  58.   o "IGMP" for link local multicasts
  59.  
  60. --------------------------------------------------------------------
  61. Wednesday, October 11, 1995
  62. --------------------------------------------------------------------
  63.  
  64. The meeting was hosted by Scott Behnke / Dyncorp and Allison Mankin / ISI.
  65.  
  66. Robert Hinden agreed to take notes for the meeting.
  67.  
  68. Steve Deering announced that Ross Callon was stepping down and Robert
  69. Hinden will be the new co-chair (and continue to be document editor).
  70.  
  71. Steve Deering reviewed standards status.  Base specification, address architecture,
  72. ICMP, and DNS specifications were approved by IESG to be Proposed Standards.
  73. Provider assignment architecture was approved for informational.  
  74. All are being submitted to RFC editor to become RFC's.
  75.  
  76. IETF last call being done for NSAP doc.  Working group last call
  77. completed for Provider Formats and Test Allocations addressing drafts.
  78. No comments on Test Alloc.  Only discussion on Provider Based was if
  79. it should be Informational, BCP, or PS.  
  80.  
  81. This Issue was discussed.  Group agreed that Provider doc should be
  82. advanced as a Proposed Standard.  Chairs will send note to IESG
  83. requesting these docs be advanced w/ cc to working group.
  84.  
  85.  
  86. ----------------------------------------------------------------------
  87. IPv6 Payload Header
  88. ----------------------------------------------------------------------
  89.  
  90. Discussion on "The IPv6 Payload Header" draft.  It would be used to
  91. identify how multiple headers (e.g., more than one TCP header) could
  92. be combined in one IPv6 packet.  Issue raised that might be hard to
  93. implement if several non-related headers were included.  It would have
  94. to be required to be implemented by everyone to be useful.  Discussion
  95. of benefits and costs.  There does not appear to be any commercial
  96. implementations of TMUX (somewhat similar for IPv4).  There does not be
  97. enough support in w.g. to advance this to the IESG at this time.
  98. Members of working group should review this document and comment if
  99. there is interest.  At this time there is not enough motivation to
  100. require this to be required for universal implementation.  Suggestion
  101. also made for some implementation experience before considering this
  102. for advancement to become a standard.  Most people have not read the draft,
  103. not much interest, author will have to make a better case.
  104.  
  105. ----------------------------------------------------------------------
  106. Addr Conf
  107. ----------------------------------------------------------------------
  108.  
  109. Sue Thomson / Thomas Narten (gave presentation) 
  110.  
  111. Open Issues: 
  112.  
  113.   o Duplicate address detection 
  114.   o Loop back semantics 
  115.   o Changing "AutoConfig" flag on running systems 
  116.   o Terminology for MAC address 
  117.   o Node vs. Router 
  118.   o Configurability of "DuplAddrDetect" 
  119.   o Separate ICMP Message for AddrConf and ND 
  120.  
  121. ------- 
  122.  
  123. Strength of Duplicate address detection 
  124.  
  125. Discussion of sending out single packet or retransmission.  Most 
  126. people thought only single NS was enough.  It would be nice to not 
  127. delay booting waiting for an answer.  Current implementations of 
  128. duplicate detection in IPv4 (using ARP) do not wait.  However, if 
  129. duplicate addresses are present, immediate use causes problems for 
  130. existing interfaces using the same address.  Waiting for DAD to 
  131. complete avoids this problem. 
  132.  
  133. Suggestion for different modes of operation depending on type of 
  134. address (autoconfigured addresses, dynamically assigned, manually 
  135. assigned). 
  136.  
  137. Suggestion for sending one NS packet, waiting a short period of time 
  138. (one second) for duplicate.  Pick generic default for Addrconf and 
  139. allow specific IPoverFoo documents to set new default value for a 
  140. particular media. 
  141.  
  142. Group agreed that default behavior should be to send single NS packet,
  143. and wait for 1 second to detect duplicates, and that these values be
  144. configurable.  A specific IPoverFoo document could define a link
  145. specific value to change default values.  The number of
  146. retransmissions is also link type specific. [See later discussion]
  147.  
  148. Discussion of how much random delay before sending NS.  The current 
  149. value is 3 sec, which is larger than the random delay used before 
  150. sending out a RS in ND. One of the differences is that all nodes will 
  151. send an NS, whereas nodes will desist from sending an RS on hearing a 
  152. RA. 
  153.  
  154. ------- 
  155.  
  156. Discussion of whether hosts can do duplicate detection and router 
  157. discovery in parallel (or does it have to be sequential).  Parallel 
  158. is preferred, since it reduces time before normal operation can start, 
  159. but requires that RAs are solicited using the unspecified address and 
  160. that RAs are multicast. [See later discussion] 
  161.  
  162. -------- 
  163.  
  164. Configurability of Duplicate Address Detection Flag 
  165.  
  166. Currently per interface configuration flag. 
  167.  
  168. Change text to require duplicate detection of link local address. 
  169. Other addresses derived using this, do not need to be checked for 
  170. duplicates.  (This avoids the problem in stateless autoconfiguration 
  171. of having different interfaces choose different addresses to apply 
  172. duplicate address detection to.) Duplicate detection required for all 
  173. stateful and manually configured addresses. 
  174.  
  175. Instead of having this flag, there are now two per interface variables 
  176. to do with duplicate address detection.  First variable indicates how 
  177. many times a solicitation is sent for duplicate detection.  Second is 
  178. timer value for interval between retransmissions.  Default values are 
  179. 1 transmission, and 1 second.  Duplicate address detection is disabled 
  180. by setting first value to zero. 
  181.  
  182. Hence, no need for separate "Duplicate address detection flag" 
  183.  
  184. -------- 
  185.  
  186. Semantics of Multicast loopback 
  187.  
  188. The current text looks OK. One further thing to consider though. 
  189.  
  190. Loopback is undesirable for general multicast applications. Thus, IPv4 
  191. multicast specification requires that driver suppress loopback. If not possible 
  192. to disable hardware, driver software needs to filter out loopback 
  193. multicast packets. If this filtering is done by comparing the source 
  194. address of the packet with that of the interface, i.e. dropping 
  195. packets whose link-layer source address is the same as that of the 
  196. interface, then this breaks DAD in the case where duplicate addresses 
  197. result from duplicate interface tokens (e.g., two interfaces both 
  198. using the same link-layer address). 
  199.  
  200. Prefer interface to not loopback multicast packets.  Approach should 
  201. be to configure hardware to not loopback, or have driver (in software) 
  202. detect duplicates with a mechanisms other than looking at the source 
  203. address. If the two previous are not possible, then a trade-off needs 
  204. to be made: allow loopback (allows duplicate address detection to 
  205. work, but inefficient in terms of multicast interrupts) or suppress 
  206. loopback by comparing source address of incoming packet and interface 
  207. (reduces number of interrupts, but disables duplicate address 
  208. detection). It is possible that an implementation might make loopback 
  209. suppression configurable in this case, i.e.  only turn it on when 
  210. duplicate address detection done. 
  211.  
  212. Agreed that text will be added to document explaining the problem, but 
  213. leave as an implementation issue how resolved. 
  214.  
  215. ---------- 
  216.  
  217. "AutoConfig" Flag 
  218.  
  219. What happens if flag turned off and on in running system? Should 
  220. addresses from previous incarnations be kept until they time out, or 
  221. should address list be reinitialized each time flag turned on? 
  222.  
  223. Discussion leading to conclusion that this should be an 
  224. implementation issue. 
  225.  
  226. Discussion of what "AutoConfig" flags means.  First, should the flag 
  227. apply to formation of the link-local address?  There was agreement 
  228. that it should not. That is, the link-local address is always formed. 
  229. The implication of this decision is that there needs to be a way for 
  230. the token to be configurable, in the (rare) case, when the token is 
  231. found not to be unique. Suggestion for advice in IPoverFoo specs for 
  232. what to do if duplicate is detected. 
  233.  
  234. Second, what part of Router Advertisements should the "AutoConfig" 
  235. flag apply to, just stateless auto-generation of global or site-local 
  236. addresses or all autoconfiguration information in router 
  237. advertisements? What does flag say about using stateful mechanism in 
  238. absence of RAs? 
  239.  
  240. One suggestion was that the "AutoConfig" Flag should only refer to the 
  241. automatic creation of addresses and bit flags telling hosts to use 
  242. DHCP (e.g., ignore this information in router advertisements).  Other 
  243. functions not affected (e.g., duplicate detection, link local, router 
  244. discovery, routing prefixes, etc.) 
  245.  
  246. Another suggestion was for two independent flags, one for disabling 
  247. stateless and one for disabling stateful autoconfiguration. 
  248.  
  249. On working through these options, it became clear that there were 
  250. several ways of defining the semantics, and that the spec need not 
  251. mandate any one way. Thus, the conclusion was to not specify specific 
  252. variables, but just for the spec to say that it should be locally 
  253. possible to disable all autoconfiguration functions, and that the 
  254. functions must be enabled by default. 
  255.  
  256.  
  257. ----------- 
  258.  
  259. Node vs. Router 
  260.  
  261. What part of the functions in the document should apply to routers? 
  262.  
  263. The conclusion was that routers are outside the scope of the document, 
  264. with the exception of formation of the link-local address and 
  265. duplicate address detection, which apply to all IPv6 nodes. 
  266.  
  267.  
  268. Discussion about whether the addr conf doc should describe how 
  269. addresses are created, or whether it should be in the IPoverFoo documents. 
  270. The latter might require IPv6 code to know about different mechanisms to 
  271. create address for each IPoverFoo type.  After discussion, group 
  272. agreed that IPoverFoo specs need to specify the rules for handling the 
  273. bits in the address token and the AddrConf spec should describe putting the 
  274. prefix and token together. 
  275.  
  276. Steve Deering suggested: Define interface tokens as bit strings. 
  277. AddrConf spec defines how to append bit strings with prefix to 
  278. form an address.  IPoverFoo specs specify how to create a bit string 
  279. and may give an example of what a link local address looks like for 
  280. this media (to avoid confusion about bit orderings). 
  281.  
  282. Prefix + address token must equal 128 bits.  Router is required to advertise 
  283. prefixes which when combined with the token for that particular interface type 
  284. add up to 128 bits. Zero padding not allowed, since padding rules may be 
  285. link-specific. 
  286.  
  287. --------- 
  288.  
  289. Terminology for MAC/Hardware address 
  290.  
  291. Should be "Link-Layer Address" 
  292.  
  293. ----------- 
  294.  
  295. Terminology 
  296.  
  297. Current spec uses the following terminology: 
  298.  
  299.     Preferred Address 
  300.     Deprecated Address 
  301.     Preferred Lifetime 
  302.            Time-till-deprecation 
  303.     Valid Lifetime 
  304.            Time-till-invalidation 
  305.  
  306. Group agreed these terms were OK. 
  307.  
  308. -------- 
  309.  
  310. Discussion about whether document applies to point-to-point links, 
  311. tunnels and NBMA networks.  Specification will be updated to clarify 
  312. that this specs requires the use of multicast on networks. This does 
  313. not mean to say, however, that parts of the spec, e.g. formation of 
  314. link-local address, may not apply to non-multicast capable networks. 
  315.  
  316. -------- 
  317.  
  318. Separate ICMP Messages for Addrconf and ND 
  319.  
  320. Jim Bound requested that different ICMP messages be used for addr conf 
  321. and ND.  He wants different machines to be able to send each type of 
  322. message.  Doesn't like the "extra" complexity of receiving combined 
  323. information. However, it was not clear how the information should be 
  324. divided up, e.g. separation of prefix advertisements from other 
  325. information advertised by routers, or separation of address-related 
  326. information (and possibly other configuration parameters) from router 
  327. advertisements, etc. 
  328.  
  329. Group conclusion was to not divide this information into separate ICMP 
  330. messages. 
  331.  
  332. ------ 
  333.  
  334. [Non- addrconf related item] 
  335. The ICMP redirect will be given a code out of the informational 
  336. instead of the error cases.  Code will be 137. 
  337.  
  338. ------ 
  339.  
  340. Group agreed that with the changes/clarifications made in this 
  341. meeting, addr conf (once revised) can go forward to Proposed Standard. 
  342.  
  343.  
  344. ----------------------------------------------------------------------
  345. Neighbor Discovery
  346. ----------------------------------------------------------------------
  347.  
  348. Erik Nordmark (presenting) & Thomas Narten
  349.  
  350.  
  351. Outstanding Issues:
  352.  
  353.   o Messages from off link sources
  354.   o Extra NUD probes for unsolicited information
  355.   o IPv6 Priority field in ND packets
  356.   o Randomizing Reachable Time
  357.   o RS with unspecified source
  358.   o Retransmission Timer = 10 sec.
  359.   o Preferences for Default Routers
  360.   o Prefix Redirects (instead of just host redirect)
  361.   o Reachable Confirmation / Negative vs. positive & Implementation Issues
  362.   o Implementation Language
  363.   o MTU Advertisements (per receiver MTU's)
  364.  
  365. -----
  366.  
  367. Messages from off link sources
  368.  
  369. Don't want to have to deal with messages which might have leaked in
  370. from outside of the local link.  Issue is malicious attach from off
  371. link.  Long discussion.  Suggestion to always do NUD using link-local
  372. address.  All advertisements would include both global and link-local
  373. address.
  374.  
  375. Suggested alternatives (to solve the off net problem) are hoplimit=0
  376. and/or "don't forward" IPv6 option.  "router process" with proper
  377. semantics would help other (somewhat related) problems.  This plus a
  378. flag could tell routers to drop these packets.  [See later discussion
  379. about hoplimits]
  380.  
  381. Much more additional discussion.  
  382.  
  383. Possible solutions to multiple NUD probes are:
  384.  
  385.   1) carry link-local in all packets
  386.   2) zero element source route.
  387.  
  388. Discussion about not using link-local address as source of this packet
  389. because it also causes an 8 packet NUD exchange.
  390.  
  391. General consensus that we should use a "do not forward" hop-by-hop
  392. option and use global source address instead of link-local address.
  393. Recipient checks if "do-not-forward" option present.  This seems to
  394. deal with off net attacks (either router drops or destination drops)
  395. and stops 8 packet NUD exchange (back to four packets with special
  396. rules or other mechanisms).
  397.  
  398. Possible choices are:
  399.  
  400.    o Carry Link local in all ND messages
  401.    o Do nothing to special to defend against off net attacks
  402.    o Don't forward option
  403.    o Keep current spec operation of saying to not do NUD for ND packets.
  404.  
  405. Queried everyone in room to gauge consensus.  Result was:
  406.  
  407.         Four said they liked "don't forward" option
  408.         Eight said they liked keep current spec
  409.         One for "Alert" option to require router to do full processing
  410.  
  411. More discussion.  Will revisit on second day of meeting after Erik
  412. Nordmark and Thomas Narten present summary of changes required to ND
  413. for making "don't forward" change.
  414.  
  415. ------------
  416.  
  417. IPv6 Priority in ND Packets
  418.  
  419. Suggestion is to make ND packets high priority (over video and audio).
  420. Proposal is to set it to 15 (highest value).
  421.  
  422. ---------------
  423.  
  424. Randomizing Reachable Time
  425.  
  426. Time to send next probe.  Each time need to send
  427.  
  428.         Range 0.5 - 1.5 (x 30 seconds)
  429.  
  430. Use this unless get new value from router advertisements.  Concern is
  431. for nets without routers, will always use same value.  Could recompute
  432. when going into PROBE state.
  433.  
  434. Issue is how often should we recompute the random number.  Current
  435. specification says recompute when new RA is received.  However, if no
  436. RAs are present, computing the value once at boot time and then never
  437. again results in some machines having a short (15 second)
  438. ReachableTime, while other machines use long (45 second) time.
  439. Recomputing each time the timer is set (e.g., whenever going into a
  440. REACHABLE state) seems excessive.
  441.  
  442. Proposal to change computed random value once a day or if hear new
  443. router advertisement.  Group thought this was a good idea and adopted
  444. it.
  445.  
  446. Randomize:  New value in Router Advertisement occasionally receive RA /
  447. once an hour
  448.  
  449. ----------------
  450.  
  451. RS with unspecified source
  452.  
  453. Needed to make initial ND startup parallel with AddrConf.  Relates to
  454. Nordmark/Narten homework assignment.  [See additional discussion]
  455.  
  456.  
  457. -------
  458.  
  459. Extra NUD Probes for Unsolicited Information
  460.  
  461. Propose to introduce STALE state.  First packet in STALE => PROBE.
  462. PROBE delays for N seconds until sending NS.
  463.  
  464. Group decided to adopt this proposal.
  465.  
  466. ---------
  467.  
  468. Retransmission Timer = 10 sec.
  469.  
  470. This is the timer used for retransmitting neighbor solicitations when
  471. node doesn't have a address or for reachability when no routers are present.
  472.  
  473. Suggestion that the default for each link type should be specified in the
  474. IPoverFoo specs.  
  475.  
  476. Group decided to Change default timer value to one (1) second.
  477. IPoverFoo spec can define link type specific default.  Value in router
  478. advertisement will override.
  479.  
  480. We can now use this timer for duplicate address detection.
  481.  
  482. ------
  483.  
  484. Prefix Redirect
  485.  
  486. Proposal for Prefix Redirects.  This would allow less redirects for
  487. traffic to same destination (and destinations in same prefix).
  488. Problem what to do when NUD detects neighbor router is down.  Does it
  489. invalidate all routes in that prefix?
  490.  
  491. No clear answer to do this.  Group will continue discussion on second
  492. day of meeting.
  493.  
  494. It was also noted that prefix redirects could be added in a backwards
  495. compatible manner (using part of the reserved field in the redirect
  496. message to specify the prefix length) should the need be stronger in
  497. the future.
  498.  
  499.  
  500. --------------------------------------------------------------------
  501. Thursday, October 12, 1995
  502. --------------------------------------------------------------------
  503.  
  504. (continuation of Prefix Redirects discussion)
  505.  
  506. Prefix redirect would result in the addition to the redirect message a
  507. length of the prefix which the redirect covers (current redirect is
  508. host style redirect).  The prefix redirect could be disabled by
  509. setting the prefix length to 128.  Hosts could either do full longest
  510. match routing or still deal with this on a per connection basis (e.g.,
  511. host route).  Discussion if people thought that routers would really
  512. implement this.
  513.  
  514. Discussion about how host and routers would deal with receiving
  515. variable length prefix redirects.  Continued discussion about merits,
  516. usage, etc.  Not clear if benefits out weigh the complexity of
  517. specifying how a host needs to deal with longest match routing.
  518.  
  519. After polling the group there was a consensus to not adding Prefix
  520. Redirects to ND.
  521.  
  522. ----------
  523.  
  524. MTU Advertisements
  525.  
  526. Proposal for hosts to be able to advertise individual MTU values.
  527. Would allow a host to have a specific MTU for it.
  528.  
  529. After discussion which pointed out the per-host MTU (or MRU) do not
  530. work with multicast the group decided not to do per-host MTU
  531. advertisements.
  532.  
  533. -------------
  534.  
  535. Benefits of "Don't Forward" Option
  536.  
  537. (homework from previous day)
  538.  
  539.   o Remove ICMP Sender address field from NS.  Results in simplified
  540.     processing.  
  541.  
  542.   o Remove "no NUD for ND Packets"
  543.  
  544.   o NS and NA use global source and destination addresses.
  545.  
  546.   o Allow link-layer address option on all packets (except unspecified
  547.     source)
  548.  
  549.   o Remove validation checks on source and destination
  550.  
  551.   o Remove "no source router header" validation check
  552.  
  553. Note: Host<-->Router control messages (RA, redirects, etc.) will still
  554. use link local addresses.  This still permits hosts to maintain their
  555. router associations in the event of renumbering.
  556.  
  557. document authors recommend that this change be made.
  558.  
  559. Bob Gilligan made proposal that instead of Hoplimit=0 or "don't
  560. forward option", could use HopLimit=255 (max value).  Host would only
  561. accept packet if HopLimit=255 when received (e.g., it had not been
  562. forwarded).  No special processing required in routers.
  563.  
  564. This would be used for all ND messages.  No "don't forward option" and no
  565. HopLimit=0.
  566.  
  567. Group agreed to adopt these changes.
  568.  
  569. ------------
  570.  
  571. Discussion about how negative advice from TCP could be use to trigger
  572. ND.  This would only be useful for on link destinations.
  573.  
  574. Additional discussion about how to use positive information from TCP.
  575. When receiving an ACK which advances TCP window, this can be used to
  576. provide positive notification that there is positive confirmation of
  577. reachability.  This can be used to update ND's state and keep NUD
  578. messages from being sent.
  579.  
  580. No change to the ND specification, but this is good advice to
  581. Implementors.
  582.  
  583. ---------
  584.  
  585. Implementations language discussion will be taken off line with
  586. document authors.
  587.  
  588. --------
  589.  
  590. Preferences
  591.  
  592. There are currently no preferences in IPv6 router advertisements.
  593. There are preferences in IPv4.  There has been a request on the
  594. mailing list that IPv6 also have preferences.
  595.  
  596. Desire for a subset of routers on a link to be given "default" status
  597. and others to not become default routers.
  598.  
  599. Discussion of pseudorouters (e.g., routers with less than full
  600. functionality) and that these type of routers might work better if
  601. there were router preferences.  Not clear if the IPng specifications
  602. should have to specify what minimum functionality that a node needs to
  603. implement.  There are too many different cases of nodes which do not
  604. do the full functionality to try to define what all of the
  605. interactions and combinations are.
  606.  
  607. Do the IPv4 semantics satisfy the request or do they need to be more
  608. sophisticated?  
  609.  
  610. ---
  611.  
  612. Thomas Narten presentation on this topic.
  613.  
  614. Current ND draft assume routers are "smart" and send redirects
  615.  
  616.  o In IPv4 reality doesn't match this ideal fix in IPV6?
  617.  
  618.  o Routers send redirects based on their own view of the topology
  619.    rather than originating hosts view.
  620.  
  621.          +--+       +---+      +---+
  622.          |  |---R2--|   |      |   |
  623.      H2--|  |       |   |--R1--|   |----H1
  624.          |  |---R2--|   |      |   |
  625.          +--+       +---+      +---+
  626.  
  627.  
  628. R3 is "good" router
  629. R2 is "bad" router
  630.  
  631. Ideally
  632.  
  633.     o R2 forwarding table needs to keep more information; routing
  634.       operation must be keyed on (arriving interface, destination)
  635.       rather than just destination.
  636.  
  637.    o Router must build separate routing tables for each arriving
  638.      interface / more computation
  639.  
  640. Does R2 have sufficient knowledge to put itself in "H2's shoes"?
  641.  
  642.    o Manually entered routers require additional arguments / flags.
  643.  
  644.    o If RIP is in use:
  645.         
  646.         - if neighbor router adjust metrics so R2 + R3 are equivalent
  647.           from H2's perspective.
  648.  
  649.         - if R2 adds 1 to each interface metric, R3 becomes better
  650.           from H2's perspective.
  651.  
  652. -----
  653.  
  654. Router advertisements w/ preferences does not eliminate requirement
  655. for "interface-specific redirect sending"
  656.  
  657.                   R1-----XXXXXXXX-----H1
  658.                  /          |
  659.                 /           |
  660.        H2 --  XXXXXX       R3
  661.                 \           |
  662.                  \          |
  663.                   R2----XXXXXXXXX------H3
  664.  
  665.   o R1 + R2 have equivalent preferences
  666.  
  667.   o H2 using R2 as current default
  668.  
  669.   o H2 sends data to H1
  670.  
  671.   o From R2's perspective H1 is one hop away via either R1 or R3 so it
  672.     chooses R3
  673.  
  674.   o From H2's perspective, R1 is clearly better
  675.  
  676.   o R2 should send different redirect to H2 + H2 (e.g., arriving
  677.     interface specific) 
  678.  
  679. --------
  680.  
  681. What is the big deal about preferences
  682.  
  683.   o Inherent conflict between preferences for "default router" vs.
  684.     router to individual destination.
  685.  
  686.   o Which router is best for destination x or default changes
  687.     dynamically
  688.  
  689.   o Routers have this information first, issue is how to best to
  690.     communicate that information to hosts
  691.  
  692.   o Possibilities:
  693.  
  694.    + Host wait for routers to tell them everything
  695.         - Redirect architecture achieves this
  696.         - Least complex host implementation, 
  697.         - NUD handles black holes
  698.  
  699.    + Hosts using defaults routes can easily switch to new default.
  700.         - Implementation can only use a single router & and does not
  701.           load balance among equal preference routers
  702.         o Still need mechanism to probe highest preference router, if
  703.           it fails. 
  704.  
  705.           Note: Latter case requires redirects to be timed out.  This
  706.           results in more redirects when nothing is changing.
  707.  
  708. ----
  709.  
  710. Steve Deering showed a slide showing that preferences do not always
  711. result in fewer packets.  Sometimes preference result in more
  712. redirect packets, sometimes not.
  713.  
  714.                  H2               H3
  715.                  |                |
  716.           #####N2####      ###N3#######
  717.              |     \       /      |
  718.              |      \     /       |
  719.              |       \   /        |
  720.              |         R1         |
  721.             R2         |         R3
  722.              |         |          |
  723.              |         |          |
  724.         ########N1########################
  725.                          |
  726.                          H1
  727.  
  728. For traffic from H1 to H3 where R1 is best router for destinations on
  729. N2 and N3
  730.  
  731.   With no router preferences:
  732.  
  733.      If R1 goes down, 50% of the time H1 will pick R3 as default
  734.      resulting in no redirect when it initiates a connection to H3.
  735.      The other 50% of the time a redirect will result.
  736.  
  737.   With router preferences of R1 being the highest, R2 next highest,
  738.   and R3 the lowest:
  739.  
  740.      If R1 goes down, H1 will always pick R2 as default.  This will
  741.      result in a redirect being sent every time H1 initiates a
  742.      connection to H3.
  743.  
  744. It is not possible to set up the router preferences in manner which
  745. results in less redirect traffic.
  746.  
  747.  
  748. ----
  749.  
  750. Narten: 
  751.  
  752. Routers learned via redirects become stale
  753.  
  754.   o Easiest is simply timeout redirects every N seconds
  755.   o # of redirects increase
  756.   o Does not eliminate the need for routers to do route calculations
  757.     based on source.
  758.   o Preference potentially reduces the need for above but does not
  759.     eliminate the need completely.
  760.  
  761. Long discussion about merits and issues regarding adding router
  762. preferences.
  763.  
  764. ------
  765.  
  766. Chair polled room on desire for router preferences:
  767.  
  768. Y= want them, N= do not think should be added
  769.  
  770. N N N N N N N N N N N (there were four non-votes)
  771.  
  772. Deering proposes we do not add preferences, do working group last
  773. call, if intensity of debate high is enough from the last call, we
  774. will not forward to IESG and continue discussion at the Dallas IETF
  775. meeting in December.
  776.  
  777. The group accepted Deering's proposal. 
  778.  
  779. ----
  780.  
  781. Discussion about the need for preferences in anycast address NA's.
  782. Anycast addresses were intended to denote "a router" rather than "the
  783. best router". In particular, the routing subsystem delivers a packet
  784. to "to a router" rather than "the best router". Thus associating
  785. preferences with anycast addresses was not really appropriate.  
  786.  
  787. After discussing the issues, group decided to not add any preferences
  788. for anycast addresses in NA.
  789.  
  790. ------
  791.  
  792. Erik Nordmark presented analysis on Boot Timing with current ND
  793. default timer values.
  794.  
  795.  
  796. Host: 
  797.  
  798.   DAD: 
  799.         Random [0-1] second delay
  800.         Send 1 NS, wait for 1 second
  801.  
  802.   RS:
  803.         Random [0-1] second delay
  804.         Send up to 3 RS separated by 3 seconds
  805.  
  806. Router:
  807.  
  808.         Receive RS
  809.         Start random timer [0-6] seconds
  810.         Timer: if received more than one RS while waiting
  811.            Send RA multicast, else unicast RA.
  812.  
  813. It should be possible to send DAD and RS at the same time, to
  814. eliminate the second random [0-1] delay.
  815.  
  816. After much discussion group decided to change so Router will respond
  817. with multicast RA (wait random [0-.5 second) and not send another RA
  818. for 3 seconds (independent of number of RS received in interval).
  819. Routers will always multicast the RA in response to an RS.  This
  820. should result in faster response to RS and fewer RA on link.  Router
  821. procedure becomes:
  822.  
  823.         Receive RS
  824.         If have not sent RA within 3 seconds
  825.            Start Random timer [0-.5] seconds
  826.            Send RA multicast
  827.          else
  828.            wait until (3 seconds + Random [0 - .5)) timer expires
  829.            Send RA multicast
  830.         endif
  831.  
  832.  
  833. ----------
  834.  
  835. Document Organization
  836.  
  837. Desire to restructure document to move packet formats to beginning of
  838. document (after overview), use standard internet bit order, make
  839. implementation details generic if appropriate, and other similar
  840. formatting changes.
  841.  
  842. Add statement that the protocol is the packet formats and external
  843. behavior on the wire and the implementation guidelines are a
  844. conceptual model.  The protocol is what is being standardized.
  845. Implementations are not required to implement guidelines exactly as
  846. described.
  847.  
  848. ------
  849.  
  850. Group agreed that once these changes are made we can do a working
  851. group last call.  Authors will have a new draft within 3 weeks.
  852.  
  853.  
  854. ----------------------------------------------------------------------
  855. Minimum Reassemble Size
  856. ----------------------------------------------------------------------
  857.  
  858. RFC of IPv6 will say that minimum reassembly size is 1500 bytes.
  859.  
  860.  
  861. ----------------------------------------------------------------------
  862. "IGMP" for Link-Local Multicast Groups
  863. ----------------------------------------------------------------------
  864.  
  865. Do membership reports need to be done for link-local multicast groups?
  866.  
  867. It is not clear if required link-local multicast addresses need to be
  868. added to IGMP group requests.  Could only use for groups which are
  869. created by the hosts and not for the required multicast group
  870. addresses.  Having them in the group would make it easier to prune
  871. traffic to groups which do not have any members.
  872.  
  873. Group decided to not include pre-defined link-local multicast
  874. addresses in IGMP group messages but will send IGMP reports for other
  875. link-local multicast addresses.
  876.  
  877. ----------------------------------------------------------------------
  878.  
  879. Thanks to Scott Behnke / Dyncorp and Allison Mankin / ISI for hosting
  880. the meeting.
  881.  
  882. Meeting adjoined!
  883.  
  884. ----------------------------------------------------------------------
  885.  
  886.  
  887.