WG ACTION: 2 weeks to discuss [LL57] Straightforward editorial fixes
Erik Guttman <[email protected]> Wed, 5 May 2004 01:02:06 +0200
| Newsgroups | gmane.ietf.zeroconf |
|---|---|
| Message-ID | <a05200f16bcbdce7de92d@[80.139.178.51]> |
Please post discussion of this issue to the mailing list over the next two weeks ending May 18, 2004. In order to accept this issued, we will need a strong WG consensus given that this is very late in the process. Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of current issues and their status. [LL57] Description of Issue: Straightforward editorial fixes Submitter Name: Stuart Cheshire Submitter Email Address: [email protected] Date first submitted: 04 May 04 Reference: Comment Type ['t'ech|'e'dit]: e Prio ['S' Must|1 should|2 may]: 1 Section: 1.9 Rationale/Explanation: Lengthy Description: Requested Change: --- >1.9. When to configure a IPv4 Link-Local address Search and replace "a IP" with "an IP" --- [Stuart] >2.4. Announcing an Address > > The host MUST then announce its claimed address by broadcasting > PROBE_N ARP announcements, spaced PROBE_MAX seconds apart. Change to: > ANNOUNCE_N ARP announcements, spaced ANNOUNCE_INTERVAL seconds apart Add to section 9: ANNOUNCE_N 2 ANNOUNCE_INTERVAL 2 seconds --- Section 2.5 > (b) If a host currently has active TCP connections or other reasons > to prefer to keep the same IPv4 address, and it has not seen any > other conflicting ARP packets recently (for IEEE 802, within the last > ten seconds) then it MAY elect to attempt to defend its address becomes If a host currently has active TCP connections or other reasons to prefer to keep the same IPv4 address, and it has not seen any other conflicting ARP packets recently (for IEEE 802, within the last | WATCH_WAIT seconds) then it MAY elect to attempt to defend its address, by recording the time that the conflicting ARP packet was received, and then broadcasting one single ARP announcement, giving its own IP and hardware addresses as the sender addresses of the ARP. Having done this, the host can then continue to use the address normally without any further special action. However, if this is not the first conflicting ARP packet the host has seen, and the time recorded for the previous conflicting ARP packet is recent (within WATCH_WAIT seconds for IEEE 802) then the host MUST immediately cease using this address and configure a new IPv4 Link-Local address as described above. This is necessary to ensure that two hosts do not get stuck in an endless loop with both hosts trying to defend the same address. --- 2.6.2 > Whichever interface is used, if the destination address is in the > 169.254/16 prefix (excluding the address 169.254.255, which is the > broadcast address for the Link-Local prefix), then the sender MUST 169.254.244 becomes 169.254.255.255 --- 3.1 > > This answer is usually answered by referring to a routing table, > > which expresses which interface (with which address) to send, and how becomes This question is usually answered by referring to a routing table, which expresses on which interface (with which address) to send, and how --- from: > >3.4. Unintentional Autoimmunity to: > >3.4. Unintentional Autoimmune Response --- 6.1 From: IPv4 Link-Local addresses used by an application may change over time. Some application software encountering an address change will fail. For example, client TCP connections will fail, to: IPv4 Link-Local addresses used by an application may change over time. Some application software encountering an address change will fail. For example, existing client TCP connections will be aborted, --- 6.2 From: > If the FTP client transmits its passive IPv4 to: > If the FTP client transmits its stale out-of-date passive IPv4 ---