Subject: [dhcwg] Is RFC 2131 Correct? ARP Request or ARP Reply ... IT IS CORRECT - BOTH ARE SENT!!

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Tue, 17 Dec 2002 15:29:42 -0600

RFC 2131 is CORRECT as it is!!! See the text below.

The first part talks about an ARP Request. This is used to solicit an
ARP reply from another host that might be using that address. If no
reply is received, then the client uses the address and THEN sends an
ARP reply. The ARP reply causes the caches in all other systems on the
LAN to be updated SHOULD THEY have an old mapping for the address (for
example, from the previous client that released the address).

Perhaps the error in RFC 2131 is that it doesn't make that fully clear.
In the last sentence of the text from 2131 below, it should have said
that if the client does not receive a reply to ARP request, it uses
the address and the client SHOULD broadcast an ARP reply ...

   If the parameters are acceptable, the client records the address of
   the server that supplied the parameters from the 'server identifier'
   field and sends that address in the 'server identifier' field of a
   DHCPREQUEST broadcast message.  Once the DHCPACK message from the
   server arrives, the client is initialized and moves to BOUND state.
   The DHCPREQUEST message contains the same 'xid' as the DHCPOFFER
   message.  The client records the lease expiration time as the sum of
   the time at which the original request was sent and the duration of
   the lease from the DHCPACK message.    The client SHOULD perform a
   check on the suggested address to ensure that the address is not
   already in use.  For example, if the client is on a network that
   supports ARP, the client may issue an ARP request for the suggested
   request.  When broadcasting an ARP request for the suggested address,
   the client must fill in its own hardware address as the sender's
   hardware address, and 0 as the sender's IP address, to avoid
   confusing ARP caches in other hosts on the same subnet.  If the

Droms                       Standards Track                    [Page 38]

RFC 2131          Dynamic Host Configuration Protocol         March 1997

   network address appears to be in use, the client MUST send a
   DHCPDECLINE message to the server. The client SHOULD broadcast an ARP
   reply to announce the client's new IP address and clear any outdated
   ARP cache entries in hosts on the client's subnet.

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Tuesday, December 17, 2002 3:32 PM
To: [email-masked]
Subject: [dhcwg] FWD: Re: IESG draft-cheshire-ipv4-acd-02.txt

Anyone care to comment on the assertion below regarding a typo in 2131?

Thomas
- ------- Forwarded Message

From: Stuart Cheshire <[email-masked]>
To: "Erik Nordmark" <[email-masked]>
Cc: <[email-masked]>
Date: Fri, 13 Dec 2002 18:45:26 -0800
Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt

At last, a reply that actually relates to the subject line.

>> > But the ongoing conflict detection (causing
>> > IP address change when a conflict appears) and broadcast replies looks
>> > more like a useful experiment to me.
>> 
>> It has been a five-year experiment by Apple.
>
>Do you have a pointer to the data that has been collected as part of
>that experiment?

There is no data. That's the point. After shipping millions of machines 
per year for five years, the number of reported problems is zero.

>How about adding
>	This document updates RFC 826 and RFC 2132.

I added a header line that says "Updates: 826, 2132"

>RFC 2131 actually talks about an ARP reply and not the ARP request
>with sender=target. See section 4.4.1 in RFC 2131.
>So you don't seem to be consistent with RFC 2131.

Stevens describes using ARP request.
BSD broadcasts an ARP request to announce its address.
Mac OS 9 broadcasts an ARP request to announce its address.
Mac OS X broadcasts an ARP request to announce its address.
Windows broadcasts an ARP request to announce its address.

RFC 2131 describes broadcasting an ARP reply, but like many things in RFC 
2131, this is probably a typo. As has been pointed out many times by many 
people, broadcasting an ARP reply is unconventional, and best avoided 
where not necessary. Therefore I avoided it and followed the behaviour 
described by Stevens (and implemented on Mac, Windows, Unix, etc.) 
instead.

In any case, the "Packet Reception" rules of RFC 826 are exceedingly 
clear that checking the packet opcode is the *last* check that is done, 
after all other packet processing has been completed.

Do you have a technical opinion to offer about which you think is best?

>I wasn't suggesting a normative reference; that isn't needed since the
>document is self-contained. But pointing out the relationship using a
>non-normative reference to draft-ietf-zeroconf-ipv6-link-local would be 
>useful for the implementors that are going to implement both.

There is already a non-normative reference to the v4ll draft.

If there is specific text you'd like to see in the draft, I'd be happy to 
consider any suggestions you wish to offer.

>>    At any time, if a host
>>    receives an ARP packet (request *or* reply) where the 'sender IP
>>    address' is the host's own IP address, but the 'sender hardware
>>    address' does not match any of the host's own interface addresses,
>>    then this is a conflicting ARP packet
>
>I fail to find the word "multihoming" or any explicit mention of
>multiple interfaces in the above text.

The phrase, "any of the host's own interface addresses" is a mention of 
multiple interfaces.

If there is specific text you'd like to see in the draft, I'd be happy to 
consider any suggestions you wish to offer.

>> > I would assume that ACD can 
>> > operate independently for each interface even though v4LL has some 
>> > extra stuff related to multi-interface nodes.
>> 
>> No, the specification needs to deal with the case when a host has two 
>> interfaces (say wireless and Ethernet) on the same link.
>
>And you claim you can't do that by having the interfaces be configured
>independently of eachother?

If there is specific text you'd like to see in the draft, I'd be happy to 
consider any suggestions you wish to offer.

>I think my conclusion was that the time should be shorter
>than 8 seconds and not longer. 8 seconds is a useless compromise
>as far as I can tell since it is unecessarily long when STP isn't triggered
>and too short when STP is triggered (with out of the box bridge
>configurations.) Thus 2 or 3 seconds should be fine.

The document already has specific text allowing shorter timeouts in cases 
where the implementer has reason to believe that is a wise design choice.

The document already has specific text describing how the individual 
choice of timeout doesn't have any impact on interoperability with other 
devices.

If there is specific text you'd like to see in the draft, I'd be happy to 
consider any suggestions you wish to offer.

>> Most network operators today, with good reason, set their port blocking 
>> time to five seconds.
>
>Doesn't match my experience. And doesn't match the IEEE 802.1D 
>recommendation.

If there is specific text you'd like to see in the draft, I'd be happy to 
consider any suggestions you wish to offer.

>Is there a way for the host to reliably detect whether the switches run 
>RSTP instead of STP?

Quoting from Mick Seaman: "Yes, the driver can easily tell the difference 
between an RSTP and an STP BPDU, they are different 'BPDU types', a type 
field being defined in the BPDU format."

If there is specific text you'd like to see in the draft, I'd be happy to 
consider any suggestions you wish to offer.

>> A Zero Configuration device may want to make use of address conflict 
>> detection. If address conflict detection requires a mandatory 
>> user-configuration option, then that means that Zero Configuration 
>> devices require mandatory user-configuration options, a 
>> self-contradiction.
>
>I'd understand that comment if it was about 
>draft-ietf-zeroconf-ipv4-link-local
>but not about the ACD document. Since the addresses are configured either
>manually or by DHCP (or some other provisioning protocol) it is possible to
>add a knob in the manual config or in DHCP, respectively. So I don't
>understand the issue your are concerned about.

I don't understand why you think there is a problem.

DHCP clients have done address conflict detection for years, and no one 
has asked for an option to disable address conflict detection there.

Macs have done address conflict detection for manual addresses for years, 
and no one has asked for an option to disable that either.

Even Windows tells you if you manually set your IP address to an address 
that's already in use.

If you've ever struggled with a network where two machines were set to 
the same IP address, you'd think it insane to ever think you'd NOT want 
to get all the help you can to diagnose and fix that problem.

I don't understand why now, after all these years of successful address 
conflict detection that no one ever complained about, there's suddenly a 
feeling that we need manual configuration options to disable it.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * Chairman, IETF Zeroconf
 * www.stuartcheshire.org

- ------- End of Forwarded Message

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg