IAONA_SysAsp_IPv4ACD_v1.0

8/22/2019 IAONA_SysAsp_IPv4ACD_v1.0

http://slidepdf.com/reader/full/iaonasysaspipv4acdv10 1/41

draft v0.4 The IAONA Handbook for Network Security 1

––

II A AOONN A A GGuuiiddeell iinnee

SSyysstteemm A Assppeeccttss IIPPvv44 A Addddr r eessss CCoonnf f ll iicctt DDeetteecctt iioonn f f oor r IInndduussttr r iiaall EEtthheer r nneett ddeevviicceess

VVeer r ssiioonn 11..00



IAONA Guideline System Aspects – IPv4 AddressConflict Detection

Version 0.6

Published by IAONA e.V.

Based on the work of IAONAs Joint Technical WorkingGroup (JTWG) System Aspects.

Recipients of this document are invited to submit, wi ththeir comments, notification of any relevant patentrights of wh ich they are aware and to providesupporting documentation.

The follow ing parties have contributed to thisdocument:

Rockwell Automation, USA Brian Batke

(Chairman J TWG System Aspects)

Heyfra electronic GmbH, D Christian Bornschein

Hirschmann, D Michael Wacker

J etter AG, D Steffen Schwips

Univ. of Magdeburg Christian Schwab

Al l il lust rat ions, charts and layout examples shown inthis document are intended solely for purposes of example. IAONA assumes no responsibility or liability(including intellectual property liability) for actual usebased upon examples given in this pub lication.

Reproduction of the contents of this copyrightedpublication, in whole or in part, without writtenpermission of IAONA is prohibited.

© IAONA, 2006IAONA e.V.Universitätsplatz 239106 [email protected]://www.iaona.org

Version 1.0 IAONA Guideline System Aspects – IPv4 Address Conflict Detection 2



Contents

1 Introduction 5 1.1 Scope of Document 5 1.2 Problem Description 5 1.3 Overview of the Solution 5

2 Cheshire IPv4 ACD Mechanism 7 2.1 Summary 7 2.2 Initial Address Probing 7 2.3 Address Announcement 7 2.4 Ongoing Conflict Detection and Defense 7 2.5 IPv4 ACD Timing Constants 8 2.6 IPv4 ACD Status and Issues 8

3 IPv4 ACD Adaptation for Industrial Devices 9 3.1 Summary 9 3.2 Timing Constants 9 3.3 Initial Address Probing 9 3.4 Address Announcement 10 3.5 Ongoing Conflict Detection and Defense 10 3.6 Additional Requirements 11 3.7 Application Protocol Fault Actions 11

3.7.1 Summary 11 3.7.2 EtherNet/IP Fault Actions 11 3.7.3

ETHERNET Powerlink Fault Actions 11

3.8 Summary of IPv4 ACD Behavior for Industrial Ethernet Devices 11

4 Implementation Considerations [Informational] 14 4.1 Summary 14 4.2 Prototype Implementation 14 4.3 Implementation Requirements 14 4.4 Example Pseudo-random Delay Algorithm 14 4.5 Issues With DHCP Clients 15 4.6 Future Direction 15

5 Idiosyncrasies Observed with IPv4 ACD Behavior [Informational] 16 5.1 Summary 16 5.2 Infinite DHCP Client Loop 16 5.3 Switches Can Drop ARP probes 16

6 Test Cases [Informational] 17 6.1 Summary 17 6.2 Tests with Other IPv4 ACD Device 17 6.3 Tests with Devices Not Supporting IPv4 ACD 19

7 References 20




Version: Date: Description:

0.1 15-J uly-05 Initial revision.

0.2 28-J uly-05 Updates: fix initial probing section related to what messages result

in conflict; make clear sections 4 through 6 are informational;remove “CIP” reference from Test Cases

0.3 29-Aug-05 Minor edits; added information on Powerlink fault action.

0.4 16-Feb-06 Made consistent with latest Cheshire Draft (added timingconstants); added latest Cheshire Draft as appendix; addedoverall state diagram; miscellaneous edits. Also made someMUST behavior SHOULD: (defend IP address, issue ongoingProbes)

0.5 15-Mar-06 Changed to guideline; further edits to make consistent withCheshire draft.

0.6 27-Mar-06 Minor edits

1.0 8-J une-06 Official version 1.0




1 Introduction

1.1 Scope of Document This document specifies a common mechanism that industrial Ethernet devices can use todetect and act upon IPv4 address conflicts. The address conflict detection (ACD)mechanism is based upon, and conforms to, the Internet Draft authored by Stuart Cheshireof Apple (see References).

In addition to specifying the ACD mechanism, this document also provides informationalmaterial and test cases to assist developers in implementing the mechanism.

This document uses the terms MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT,etc., consistent with the common usage in RFCs (see RFC 2110).

1.2 Problem Description

Unpredictable and undesirable behavior results when multiple devices attempt to use thesame IP address. An example address conflict scenario is shown below:

Device A starts up and uses IP address 10.88.80.10

Other devices establish communications with Device A

Device B has incorrectly been configured to also use 10.88.80.10

Device B starts up and sends an ARP announcement

Existing communications to Device A are disrupted and reestablished with Device B(though this is not necessarily always the case)

New communications initiated by other devices could go to Device A or Device B (ormay be established and disrupted again)

In such situations, it can be difficult to determine that there even is an address conflictsituation, and where the offending device is located.

To further complicate the problem, there is no universally implemented mechanism fordetecting IP address conflicts. A Windows PC typically displays a pop-up message if it

receives a response to ARP announcement messages sent at startup. Some embeddeddevices follow the Windows behavior, but in general there is no common behavior forembedded devices.

It is desirable to have a common IP address conflict detection mechanism for industrialEthernet devices. A common mechanism enables consistent behavior and helps the user indiagnosing address conflict conditions.

1.3 Overview of the Solution

The ACD mechanism for industrial Ethernet devices is based on the Internet Draft for IPv4

Address Conflict Detection (referred to as IPv4 ACD) developed by Stuart Cheshire of Apple. The most recent version of the IPv4 ACD draft is included as Appendix A in this document.

The IPv4 ACD mechanism involves the following aspects:




1. Initial probing: before using an IP address the device issues ARP Probes to seewhether the address is in use.

2. Address announcement: after the initial probing the device issues ARPannouncements.

3. Ongoing conflict detection and defense: the device performs ongoing address conflictdetection and potentially defends its address.

In addition to specifying the use of the Cheshire IPv4 ACD mechanism, this documentspecifies additional requirements for industrial Ethernet devices with respect to the IPv4 ACDmechanism. Additional aspects include:

• Timing of ARP probes

• Address defense behavior

• Device fault behavior




2 Cheshire IPv4 ACD Mechanism

2.1 Summary This section summarizes the essential aspects of the Cheshire IPv4 ACD mechanism asspecified in the Internet Draft. For a full description of the mechanism, refer to the IPv4 ACDInternet Draft included in Appendix A.

2.2 Initial Address Probing

Before using an IP address a host must determine if the address is already in use. Initialaddress probing must be done regardless of whether the address was obtained via BOOTP,DHCP, or via other means (e.g., manual configuration).

In order to determine whether an address is already in use, the host waits for an initialrandom delay, then issues ARP probes (an ARP request with the target IP address inquestion and sender IP address of all 0).

The use of ARP probes for the initial conflict detection is beneficial since hosts will notupdate their ARP caches upon receipt of an ARP probe. As a result, if a host is alreadyusing an IP address and a second host starts up and probes for the address, thecommunications to the original host will not be disrupted.

During initial ARP probing, if any ARP message is received with the Sender IP Addressmatching the address being tested, then a conflict has been detected. In addition, if an ARP

probe is received with the Target IP Address matching the address being tested (and theSender Hardware Address does not match any of the host’s interfaces) then a conflict isdetected.

2.3 Address Announcement

After the initial address probing has been completed, and no conflict has been detected, thehost must issue ARP announcements (ARP request with the target IP address and sender IPaddress set to the address in question) to announce its use of the address.

2.4 Ongoing Conflict Detection and DefenseAfter initial address probing and announcement, hosts must perform ongoing conflictdetection and defense. A conflict is detected if the host receives an ARP message (requestor reply) with a Sender IP Address that matches the host’s IP address. Note: ARPmessages that contain the host’s own hardware address in the Source Hardware Addressfield are NOT treated as conflicts.

When a conflict is detected after the initial probing, a host has 3 options:

a. Cease using the address.

b. Attempt to defend the address by issuing an ARP announcement, provided a conflictwas not detected within the last DEFEND_INTERVAL seconds (in order to prevent apersistent conflict/defend condition with another host that does not implement theACD mechanism).




c. Defend the address indefinitely if configured to do so. This might be the course of action taken by routers or other servers with fixed, permanent IP addresses. Asabove, there is an additional requirement that a host defending an address not senddefensive ARP announcements more frequently than every DEFEND_INTERVALseconds.

2.5 IPv4 ACD Timing Constants

The IPv4 ACD Draft specifies a number of timing-related constants. The constants areshown below, with their nominal values:

PROBE_WAI T 1 second ( i ni t i al r andomdel ay)

PROBE_NUM 3 ( number of probe packet s)

PROBE_MI N 1 second ( mi ni mumdel ay unt i l r epeat ed probe)

PROBE_MAX 2 seconds ( maxi mum del ay unt i l r epeated probe)

ANNOUNCE_WAI T 2 seconds ( del ay bef or e announci ng)

ANNOUNCE_NUM 2 ( number of announcement packet s)

ANNOUNCE_I NTERVAL 2 seconds ( t i me bet ween announcement packet s)

MAX_CONFLI CTS 10 ( max conf l i ct s bef ore r ate l i mi t i ng)

RATE_LI MI T_I NTERVAL 60 seconds ( del ay bet ween successi ve at t empts)

DEFEND_I NTERVAL 10 seconds ( mi ni mum i nterval bet ween def ensi ve ARPs)

Note: Since some of these values are not optimal for industrial networking devices, alternatevalues are specified in Section 3.

2.6 IPv4 ACD Status and Issues

Previous correspondence with the Draft’s author indicated that the IPv4 ACD Internet Drafthad been accepted by the IETF Zeroconf Working Group, and was waiting further dispositionby the Internet Area Coordinator.

While it seems likely that the IPv4 ACD Draft will become an RFC, this is not guaranteed.Industrial Ethernet devices can still implement the mechanism, per the Internet Draft(included in Appendix A of this document) and the adaptation requirements for industrialEthernet devices. Indeed, the IPv4 ACD mechanism has been present for several years inApple-developed operating systems.

Note: the ACD mechanism as specified here recommends that periodic ARP probes be sentas part of ongoing detection. [Cheshire05] states that “hosts Must Not perform this checkperiodically as a matter of course” (section 2.1). It has been demonstrated that the periodicprobes are necessary to detect conflicts in some situation: for example, when a simple targetis not connected to the larger network when powered up, or when switches drop initial ARPprobes due top initial forwarding delay. It is hoped that the conflict with [Cheshire05] isresolved in a newer version of the document.




3 IPv4 ACD Adaptation for Industrial Devices

3.1 Summary

In order to make the IPv4 ACD mechanism feasible for industrial Ethernet devices, and toachieve consistent behavior, it is necessary to specify a number of particular requirementswith respect to the Cheshire IPv4 ACD Internet Draft.

Unless otherwise specified, industrial Ethernet devices MUST follow the Cheshire InternetDraft.

3.2 Timing Constants

The IPv4 ACD Draft specifies a number of timing-related constants, some of which are notoptimal for industrial Ethernet applications. In particular, the start up delays cause by the

ARP probe intervals would be unacceptable in the industrial setting.

The following list shows the alternate values that MUST be used (constants not listed areunchanged from the IPv4 ACD Draft):

PROBE_WAI T 200 ms ( i ni t i al r andom del ay)


PROBE_MI N 200 ms ( mi ni mum del ay unt i l r epeated probe)

PROBE_MAX 200 ms ( maxi mum del ay unt i l r epeat ed probe)

ANNOUNCE_WAI T 200 ms ( del ay bef or e announci ng)

In addition to the above constants, this specification introduces additional constants for usewhen sending ARP probes as part of ongoing conflict detection:

ONGOI NG_PROBE_MI N 90 seconds ( mi ni mum i nterval f or ongoi ng probes)

ONGOI NG_PROBE_MAX 150 seconds ( maxi mum i nt er val f or ongoi ng probes)

3.3 Initial Address Probing

For the initial address probing, industrial Ethernet devices MUST do the following:

• Perform initial address probing before using an IP address – at power up and any othertime the IP address is configured or changed. The IP address MUST be probedregardless of whether the address was obtained via BOOTP, DHCP, or staticconfiguration (see also section 4.5, Issues with DHCP Clients).

• Do not start the initial address probing until Ethernet Link Integrity has been detected.

• The initial delay before probing SHOULD be “randomized” in order to avoid a situationwhere many like devices power up and send ARP probes simultaneously. There area number of ways to generate a pseudo-random number in the range of 0-PROBE_WAIT (200 ms as specified above). A simple method is to performarithmetic on the Ethernet address to produce an initial delay value (e.g., perform“modulo” arithmetic on the Ethernet address and use the remainder as the initialdelay in ms). Refer to Section 4.4 for an example.




• If a conflict is detected during the initial probing, the device MUST do the following:

o The device shall not use the IP address.

o Take the fault action as specified by the particular application protocol suite(EtherNet/IP, ModBus/TCP, etc.) Refer to section 3.7 for the address conflictfault actions.

o If the address was obtained via DHCP, the device MUST take one of twoactions:

1. Issue a DHCPDECLINE, remain in the address conflict state and donot restart the DHCP client state machine until the device is reset. This is the recommended action, since it addresses the situationwhere a misconfigured server continues to give out the same (fixed)address.

2. Issue a DHCPDECLINE, then restart the DHCP client state machine tothe Init state (issue DHCPDISCOVER). The device MUST limit the rateat which new addresses are requested and probed, per the CheshireInternet Draft (i.e., after MAX_CONFLICT conflicts the device mustprobe for new addresses no more than once per minute).

o If the address was obtained via BOOTP, do NOT reissue BOOTP requestssince the BOOTP server will simply reissue the same address.

o If the device has another communications port over which it can beconfigured, the device SHOULD allow the user to set a new, non-conflicting IPaddress.

3.4 Address Announcement

There are no additional requirements beyond the Cheshire Draft.

3.5 Ongoing Conflict Detection and Defense

After an IP address has successfully been probed and put into use, a device MUST performongoing conflict detection and defense according to the Cheshire Draft, with the followingspecific requirements:

• If a conflict is detected the device SHOULD attempt to defend its address per Option(b) in the Cheshire Draft. Under most circumstances, a device SHOULD attempt todefend its address. However there are some circumstances where a device mayelect not to defend its address. For example, if a mobile device detects a conflict, it isreasonable to assume the mobile device is the problem. In this case it is better for themobile device to cease using the address.

• If a conflict persists (as defined by the Draft) the device must then follow the behavioras when a conflict is detected during initial probing (device state, LEDs, DHCPbehavior, etc.).

• The device SHOULD issue periodic ARP probes within the range of ONGOING_PROBE_MIN and ONGOING_PROBE_MAX (“randomized” usingEthernet MAC address). The periodic ARP probes allow the module to detectconflicts with devices that may not have been connected to the network at the time of




initial probing, or when switches have dropped the initial ARP probes due to initialforwarding delay.

3.6 Additional Requirements

• Devices MUST respond to ARP probes. Note that some older TCP/IP implementationsignored ARP probes.

• When a device detects that Ethernet link integrity has been lost and then regained(e.g., the network cable has been removed and replaced), the device MUST re-startthe initial conflict detection behavior.

3.7 Application Protocol Fault Actions

3.7.1 Summary

When an address conflict is detected, each IAONA application protocol may have specificactions to be taken, in the context of that procotol. For example, a protocol-specific statusword may be set, and LED or other indicator may be changed, etc.

This section describes the fault actions that have been defined to date for IAONA applicationprotocols. When fault actions are defined for other IAONA application protocols, they will beadded to this document.

3.7.2 EtherNet/IP Fault Act ions

When an address conflict is detected, during the initial probing or ongoing detection phases,EtherNet/IP devices take the following fault actions:

• Set the device state to Recoverable Fault (Module Status LED flashing red).

• Set the Network Status LED to solid red.

3.7.3 ETHERNET Powerl ink Fault Act ions

The address conflict will be logged with error code E_DLL_ADDRESS_CONFLICT (8201h) andthe respective time stamp into the error history every time it occurs. The conflicting nodes willbe set inactive.

3.8 Summary of IPv4 ACD Behavior for Industr ial EthernetDevices

As an aid to developers, the following table and diagrams summarize the IPv4 ACD behaviorfor industrial Ethernet devices:

Phase Summary of Behavior Causes of Conflict Action Taken WhenConflict is Detected

Initial Probing 1. Don’t probe untilEthernet Link Integritydetected.

1. ARP probe witha matching TargetIP Address.

1. Do not use IP address.

2. Take protocol-specificfault action.




2. Delay from 0 toPROBE_WAIT,randomized.

3. Issue PROBE_NUMARP probes at intervalbetween PROBE_MIN

and PROBE_MAX.

3. Listen for incoming ARPpackets and check forconflict.

2. ARP message(request or reply)with a matchingSender IPAddress.

ARP packets withthe SourceHardware addressmatching thedevices’ EthernetMAC address areNOT conflicts.

3. If address obtained viaDHCP, device isRECOMMENDED to

remain in conflict state.

4. If address obtained viaBOOTP, device mustremain in conflict state.

5. If the device hasanother communications

port over which it can beconfigured, the deviceshould allow the user toset a new, non-conflictingIP address.

OngoingDetection

1. Listen for incoming ARPpackets and check forconflict.

2. Respond to ARP Probes(as well as normal ARPrequests).

3. The device should issueperiodic ARP Probes (atintervals betweenONGOING_PROBE_MINandONGOING_PROBE_MAX).

4. Restart Initial Probingwhen Ethernet LinkIntegrity is lost and then

regained.

1. ARP message(request or reply)with a matchingSender IPAddress.

ARP packets withthe SourceHardware addressmatching the

devices’ EthernetMAC address areNOT conflicts.

1. If no conflicts havebeen detected in the lastseconds, the deviceshould attempt to defendthe address by sendingan ARP announcement.

2. If the conflict persists(i.e., another conflict isdetected within

DEFEND_INTERVAL),the device must follow thesame conflict behavior asin the initial probingphase (see above).




Overall ACD

Behavior

Allocate IP Address

Address Probing

Wait for Link Integrity

Address Announcement

IP addrchanged

Link Lost

Link Lost

Link up

Link up

Protocol Fault Action

Address allocated

Ongoing Detection

and Defense

Address probed

Address announced

Fault action takenConflict detected

etectedConflict d

Ethernet Link Integrity(Initialization Phase)




4 Implementation Considerations [Informational]

4.1 Summary

At present, the IPv4 ACD mechanism is not implemented in any common embeddedoperating systems. Consequently, developers must in general implement IPv4 ACD outsideof the TCP/IP stack with which they have been provided.

This section discusses some of the considerations and issues of interest to developers whenimplementing the IPv4 ACD mechanism.

4.2 Prototype Implementation

The IPv4 ACD mechanism has been prototyped and demonstrated. The prototype wasimplemented on a standard operating system and required the following:

• Create and send ‘raw’ ARP requests in order to perform the initial address probingbefore initializing the device’s IP address.

• Modifications to the Ethernet driver to receive ARP messages, check for a conflictingaddress, and signal that a conflict exists.

• Task-level code to process address conflicts (defend, release, change device status,etc.).

4.3 Implementation Requirements

In general, implementing IPv4 ACD in an industrial Ethernet device requires:

• Ability to send ARP probes and ARP announcements.

• Ability to receive ARP messages (requests and responses), check for conflicts andnotify application code of the conflict.

• Ability to perform initial probes BEFORE initializing the Ethernet interface with thedesired IP address.

• Ability to perform ongoing detection and defense and take the appropriate action if a

conflict is detected (defend, release, etc.).

• Note that the ability to send and receive ARP messages will vary depending onembedded OS. In many cases, modification to the device’s Ethernet driver isrequired.

4.4 Example Pseudo-random Delay Algorithm

The following shows an example algorithm that might be used to produce an initial pseudo-random delay before sending out ARP probes, assuming an initial PROBE_WAIT of 200 ms:

AcdProbeTime = 200;

AcdDelay = EnetAddr[0];




AcdDelay = ( AcdDelay << 1 ) ^EnetAddr[1];





AcdDelay = ( AcdDelay – (( AcdDelay mod AcdProbeTime ) * AcdProbeTime ));

4.5 Issues With DHCP Clients

Existing DHCP client implementations in commercial operating systems do not incorporatethe IPv4 ACD mechanism. Unless access to DHCP client source code is possible, devicesmay need to perform the conflict detection mechanism outside of the DHCP client.

The preferred approach is to allow the DHCP client to manage obtaining the address lease

but not control the actual setting of the IP address. The DHCP client obtains the addressand lease, and the ACD implementation then probes for conflicts. If a conflict is found, theaddress is not used, the DHCP client is told to release the lease, and the device remains inthe conflict state (as in section 3.2).

In some implementations, the DHCP client may use the obtained IP address before theapplication can perform the initial address probing. In this case, the application MUSTperform the initial address probing as soon as is feasible. If a conflict is detected, the devicemust remain in the conflicted state (see section 3.3, Initial Address Probing).

4.6 Future Direction

Long term, it is expected that embedded operating system vendors will adopt the IPv4 ACDmechanism.




5 Idiosyncrasies Observed with IPv4 ACD Behavior [Informational]

5.1 SummaryDuring testing of the initial IPv4 ACD implementation, a number of idiosyncrasies wereobserved. This section discusses observed IPv4 ACD behaviors that may be of interest todevelopers.

5.2 Infinite DHCP Client Loop

Some DHCP clients can remain in an infinite loop when fixed addresses are used and anaddress conflict is detected. At least one embedded DHCP client implementation does itsown rudimentary conflict detection by issuing an ARP probe of the newly acquired address.

If a conflict is detected, the client requests a new address from the server. If the DHCPserver responds with the same fixed IP address, the client enters into an endless loop of requesting an address from the server.

The ACD implementation may detect this condition by explicitly examining incoming ARPmessages and knowing whether the DHCP client is running. In this situation, it isrecommended that the device stop its DHCP client and remain in the address conflict state(see Section 3).

5.3 Switches Can Drop ARP probes

When a switch port has the Spanning Tree Protocol, initial packets from the end devices willnot be forwarded to the network for some period of time – typically 15-30 seconds. In thiscase, a device’s initial ARP probes will not be seen by other devices. It is recommended thatSpanning Tree be disabled on switch ports to which end devices are connected.




6 Test Cases [Informational]

6.1 Summary

This section suggests test cases for devices that implement the IPv4 ACD mechanism. Thetest cases are not meant to be an exhaustive list, but rather are a minimal set of suggestedtests in order to verify an IPv4 ACD implementation.

6.2 Tests with Other IPv4 ACD Device

The following tests should be performed with the Device Under Test (DUT) and asecond device that implements the IPv4 ACD mechanism. Tests should beperformed with addresses assigned via BOOTP, DHCP (if supported), and staticconfiguration.

Test Device Under Test Device 2 (with ACD)

1. Power up DUT and wait until it

passes the initial probing phase.

Power up device #2. No

communications associations.

Keeps IP address Detects conflict, gives up

IP address.

2. Power up DUT. Establish

communications with DUT.

Power up device #2.

Keeps IP address.

Communication with

device remains open

Detects conflict, gives up

IP address.

3. Power up device #2. Establish

communications to device #2.

Power up DUT with no cable.

Attach cable to DUT.


IP address.

Keeps IP address.

Communication with

device remains open.



Disconnect cable. Power up

device #2 and wait until it passes

the initial probing phase.

Reattach cable to DUT.


IP address.

Keeps IP address

5. Power up DUT and device #2,with each connected to different

hubs/switches with no link

Either DUT or device #2detects conflict within

ONGOING PROBE MAX,

Either DUT or device #2detects conflict within

ONGOING PROBE MAX,




between the hubs/switches.

Make sure each device has

passed the initial probing phase.

Then connect the hubs/switches.

depending on which

device probes first.

Also possible that both

devices detect conflict,depending on timing of the

ARP probes.

depending on which


Also possible that both

devices detect conflict,depending on timing of the

ARP probes.

6. Power up DUT and device #2

“simultaneously”, such that they

both are doing ARP probes at the

same time.

Either DUT or device #2

detects conflict within the

initial probing period,

depending on which


Also possible that bothdevices detect conflict,

depending on timing of the

ARP probes.

Either DUT or device #2

detects conflict within the

initial probing period,

depending on which


Also possible that bothdevices detect conflict,

depending on timing of the

ARP probes.




6.3 Tests with Devices Not Supporting IPv4 ACD

The following tests should be performed with the Device Under Test (DUT) and a

second device that DOES NOT implement the IPv4 ACD mechanism. Tests shouldbe performed with addresses assigned via BOOTP, DHCP (if supported), and staticconfiguration.

Test Device Under Test Device 2 (without ACD)


passes the initial probing phase. Power

up device #2. No communication

associations.

In general, detects conflict

and gives up IP address.

May defend address if

other device issues ARPprobes (e.g., Windows

devices).

Variable



Establish communications with DUT.

Power up device #2.

Same as above. Variable.

3. Power up device #2. Power up DUT

with no cable. Attach cable to DUT.


IP address.

Variable.



Disconnect cable. Power up device #2.

Reattach cable to DUT.


IP address.

Variable.

5. Power up DUT and device #2, with

each connected to differenthubs/switches with no link between the

hubs/switches. Make sure DUT has

passed the initial probing phase. Then

connect the hubs/switches.

Conflict should be

detected withinONGOING_PROBE_MAX,

gives up IP address.

Variable.




7 References

[Cheshire05] Stuart Cheshire, “IPv4 Address Conflict Detection”, Internet Draft, 11-J uly-2005.

[IAONA03] IAONA JTWG "Wiring Infrastructure": IAONA Industrial Ethernet Planningand Installation Guide. IAONA, Magdeburg 2003

www.iaona.org

[IndI06] IAONA Handbook Industrial Ethernet: IAONA, Magdeburg 2003

www.iaona.org




Appendix A – IPv4 Address Conflict Detection Internet Draft

This section includes the most version of the IPv4 Address Conflict Detection Draft.

Document : dr af t - cheshi r e- i pv4- acd- 04. t xt St uar t Cheshi r e

Category: Standar ds Track Appl e Comput er

Updates: 826 11t h J ul y 2005

Expi r es 11t h J anuary 2006

I Pv4 Addr ess Conf l i ct Det ect i on

<dr af t - cheshi r e- i pv4- acd- 04. t xt>

Status of t hi s Memo

By submi t t i ng t hi s I nt er net - Dr af t , each aut hor r epr esent s t hat any

appl i cabl e patent or other I PR cl ai ms of whi ch he or she i s awar e

have been or wi l l be di scl osed, and any of whi ch he or she becomes

aware wi l l be di scl osed, i n accor dance wi t h Sect i on 6 of BCP 79.

For t he pur poses of t hi s document , t he t erm "BCP 79" r ef er s

excl usi vel y t o RFC 3979, "I nt el l ect ual Pr oper t y Ri ght s i n I ETF

Technol ogy", publ i shed Mar ch 2005.

I nt er net - Dr af t s are wor ki ng document s of t he I nt er net Engi neer i ng

Task For ce ( I ETF) , i t s ar eas, and i t s wor ki ng groups. Not e t hat

other gr oups may al so di st r i but e worki ng document s as I nt ernet -

Dr af t s.

I nt er net - Dr af t s are dr af t document s val i d f or a maxi mum of si x mont hs

and may be updated, r epl aced, or obsol eted by ot her document s at any

t i me. I t i s i nappr opr i at e t o use I nt er net - Dr af t s as r ef er ence

mat er i al or t o ci t e them ot her t han as "wor k i n pr ogr ess. "

The l i st of cur r ent I nt er net - Dr af t s can be accessed at

ht t p: / / www. i et f . or g/ 1i d- abst r acts. ht ml

The l i st of I nt ernet - Dr af t Shadow Di r ect or i es can be accessed at

ht t p: / / www. i et f . or g/ shadow. ht ml

Abst r act




When two host s on t he same l i nk at t empt t o use t he same I Pv4 address

at t he same t i me ( except i n r are speci al cases wher e t hi s has been

arr anged by pr i or coor di nat i on) pr obl ems ensue f or one or both host s.

Thi s document descr i bes ( i ) a si mpl e precaut i on t hat a host can t akei n advance to hel p pr event t hi s mi sconf i gur at i on f r om happeni ng, and

( i i ) i f t hi s mi sconf i gur at i on does occur , a si mpl e mechani sm by whi ch

a host can passi vel y det ect af t er - t he- f act t hat i t has happened, so

t hat t he host or admi ni st r at or may respond t o r ect i f y the pr obl em.

1. I nt r oducti on

Hi st or i cal l y, acci dent al l y conf i gur i ng t wo I nt er net host s wi t h t he

same I P addr ess has of t en been an annoyi ng and hard- t o- di agnose

probl em.

Thi s i s unf or t unat e, because t he exi st i ng ARP prot ocol provi des

an easy way f or a host t o detect t hi s ki nd of mi sconf i gur at i on and

r epor t i t t o t he user . The DHCP speci f i cat i on [ RFC2131] br i ef l y

ment i ons t he rol e of ARP i n det ect i ng mi sconf i gur at i on, as

i l l ust r at ed i n t he f ol l owi ng t hr ee excer pt s f r om RFC 2131:

o the cl i ent SHOULD probe the newl y recei ved address,

e. g. , wi t h ARP.

o The cl i ent SHOULD per f orm a f i nal check on t he parameters

( e. g. , ARP f or al l ocat ed net wor k addr ess)

o I f t he cl i ent det ect s t hat t he addr ess i s al r eady i n use

( e. g. , t hr ough t he use of ARP) , t he cl i ent MUST send

a DHCPDECLI NE message t o t he ser ver

Unf or t unatel y, t he DHCP speci f i cat i on does not gi ve any gui dance t o

i mpl ement ers concer ni ng t he number of ARP packet s t o send, t he

i nt er val bet ween packet s, t he t ot al t i me t o wai t bef or e concl udi ng

t hat an address may saf el y be used, or i ndeed even whi ch ki nds of

packet s a host shoul d be l i st eni ng f or , i n or der t o make t hi s

det er mi nat i on. I t l eaves unspeci f i ed t he act i on a host shoul d t ake

i f , af t er concl udi ng t hat an addr ess may saf el y be used, i t

subsequent l y di scover s t hat i t was wr ong. I t al so f ai l s t o speci f y

what pr ecaut i ons a DHCP cl i ent shoul d t ake to guard agai nst




pat hol ogi cal f ai l ur e cases, such as DHCP ser ver t hat r epeat edl y

OFFERs t he same addr ess, even t hough i t has been DECLI NEd mul t i pl e

t i mes.

The authors of t he DHCP speci f i cat i on may have have been j ust i f i edi n thi nki ng at t he t i me that t he answer s t o t hese quest i ons seemed

t oo si mpl e, obvi ous and st r ai ght f or ward t o be wor t h ment i oni ng, but

unf or t unat el y t hi s l ef t some of t he bur den of pr ot ocol desi gn t o each

i ndi vi dual i mpl ement er . Thi s document seeks t o r emedy t hi s omi ssi on

by cl ear l y speci f yi ng t he r equi r ed act i ons f or :

1. Determi ni ng whether use of an addr ess i s l i kel y to l ead t o an

addr essi ng conf l i ct . Thi s i ncl udes (a) t he case wher e t he addr ess

i s al r eady act i vel y i n use by anot her host on the same l i nk, and

( b) t he case wher e two host s are i nadver t ent l y about t o begi n

usi ng t he same addr ess, and bot h are si mul t aneousl y i n t he pr ocess

of probi ng t o det ermi ne whet her t he address may saf el y be used.

( Secti on 2. 1. )

2. Subsequent passi ve detect i on t hat anot her host on t he net work i s

i nadver t ent l y usi ng t he same addr ess. Even i f al l host s obser ve

pr ecaut i ons t o avoi d usi ng an addr ess t hat i s al r eady i n use,

conf l i ct s can st i l l occur i f t wo host s are out of communi cat i on at

t he t i me of i ni t i al i nt er f ace conf i gur at i on. Thi s coul d occur

wi t h wi r el ess net wor k i nt er f aces i f t he host s are t empor ar i l y out

of r ange, or wi t h Et her net i nt er f aces i f t he l i nk bet ween t wo

Et her net hubs i s not f unct i oni ng at t he t i me of addr ess

conf i gur at i on. A wel l - desi gned host wi l l handl e not onl y

conf l i cts det ected dur i ng i nt er f ace conf i gur at i on, but al so

conf l i cts det ected l at er , f or t he ent i r e dur at i on of t he t i me

t hat t he host i s usi ng t he addr ess. ( Sect i on 2. 4. )

3. Rat e- l i mi t i ng of addr ess acqui si t i on at t empt s i n t he case of

an excessi ve number of r epeat ed conf l i ct s. ( Sect i on 2. 1. )

The ut i l i t y of I Pv4 Address Conf l i ct Det ect i on ( ADC) i s not l i mi t ed

t o DHCP cl i ent s. No mat t er how an address was conf i gur ed, whet her

vi a manual ent r y by a human user , vi a i nf or mat i on recei ved f r oma

DHCP ser ver , or vi a any ot her sour ce of conf i gur at i on i nf or mat i on,

det ecti ng conf l i cts i s usef ul . Upon det ecti ng a conf l i ct, t he

conf i gur i ng agent shoul d be not i f i ed of t he er r or . I n t he case wher e




t he conf i gur i ng agent i s a human user , t hat not i f i cat i on may t ake t he

f orm of an err or message on a screen, an SNMP t r ap, or an err or

message sent vi a pager . I n t he case of a DHCP server , t hat

not i f i cat i on t akes t he f or m of a DHCP DECLI NE message sent t o t he

ser ver . I n t he case of conf i gur at i on by some ot her ki nd of sof t war e,t hat not i f i cat i on t akes the f or m of an er r or i ndi cat i on t o t he

sof t war e i n quest i on, t o i nf or m i t t hat t he addr ess i t sel ected i s

i n conf l i ct wi t h some ot her host on t he net wor k. The conf i gur i ng

sof t ware may choose t o cease network operat i on, or i t may

aut omat i cal l y sel ect a new addr ess so t hat t he host may r e- establ i sh

I P connect i vi t y as soon as possi bl e.

Al l ocat i on of I Pv4 Li nk- Local Addr esses [ RFC3927] can be t hought of

as a speci al - case of t hi s mechani sm, wher e t he conf i gur i ng agent i s

a pseudo- r andom number gener ator , and t he act i on i t t akes upon bei ng

not i f i ed of a conf l i ct i s t o pi ck a di f f er ent r andom number and t r y

agai n. I n f act , t hi s i s exact l y how I Pv4 Li nk- Local Addr essi ng was

i mpl ement ed i n Mac OS 9 back i n 1998. I f t he DHCP cl i ent f ai l ed t o

get a r esponse f r om any DHCP server , i t woul d si mpl y make up a f ake

r esponse cont ai ni ng a r andom 169. 254. x. x addr ess. I f t he ARP modul e

r epor t ed a conf l i ct f or t hat addr ess, t hen t he DHCP cl i ent woul d t r y

agai n, maki ng up a new r andom 169. 254. x. x address as many t i mes as

was necessary unt i l i t succeeded. I mpl ement i ng ACD as a st andar d

f eat ur e of t he net wor ki ng st ack has t he si de- ef f ect t hat i t means

t hat hal f t he wor k f or I Pv4 Li nk- Local Addr essi ng i s al r eady done.

1. 1. Convent i ons and Ter mi nol ogy Used i n t hi s Document

The key wor ds "MUST", "MUST NOT", "REQUI RED", "SHALL" , "SHALL NOT",

"SHOULD", "SHOULD NOT", "RECOMMENDED" , "MAY", and "OPTI ONAL" i n t hi s

document ar e t o be i nt er pr et ed as descr i bed i n "Key words f or use i n

RFCs t o I ndi cate Requi r ement Level s" [ RFC2119] .

Wherever t hi s document uses t he t er m "sender I P addr ess" or " t ar get

I P addr ess" i n t he cont ext of an ARP packet , i t i s r ef er r i ng t o t he

f i el ds of t he ARP packet i dent i f i ed i n t he ARP speci f i cat i on [ RFC826]

as "ar$spa" ( Sender Pr ot ocol Addr ess) and "ar $t pa" ( Target Protocol

Addr ess) r espect i vel y. For t he usage of ARP descr i bed i n t hi s

document , each of t hese f i el ds al ways cont ai ns an I Pv4 addr ess.

I n t hi s document , t he t erm "ARP Pr obe" i s used t o r ef er t o an ARP




Request packet , br oadcast on the l ocal l i nk, wi t h an al l - zer o ' sender

I P addr ess' . The ' sender har dware addr ess' MUST cont ai n t he har dware

addr ess of t he i nt er f ace sendi ng t he packet . The ' sender I P addr ess'

f i el d MUST be set t o al l zer oes, t o avoi d pol l ut i ng ARP caches i n

other host s on t he same l i nk i n the case wher e the address t ur ns outt o be al r eady i n use by anot her host . The ' t ar get har dwar e addr ess'

f i el d i s i gnor ed and SHOULD be set t o al l zer oes. The ' t ar get I P

address' f i el d MUST be set t o t he address bei ng probed. An "ARP

Probe" conveys bot h a quest i on ( " I s anyone usi ng thi s addr ess?" )

and an i mpl i ed st at ement ( "Thi s i s t he addr ess I i nt end t o use. " ) .

I n thi s document , t he term "ARP Announcement " i s used to ref er t o

an ARP Request packet , br oadcast on t he l ocal l i nk, i dent i cal t o

t he ARP pr obe descr i bed above, except t hat bot h t he sender and

t ar get I P addr ess f i el ds cont ai n t he I P addr ess bei ng announced.

I t conveys a st r onger st atement t han an "ARP Probe", namel y,

"Thi s i s t he addr ess I am now usi ng. "

The f ol l owi ng t i mi ng const ants ar e used i n t hi s prot ocol ; t hey ar e

not i nt ended t o be user- conf i gur abl e. These const ant s are r ef er enced

i n Sect i on 2, whi ch descri bes t he oper at i on of t he pr ot ocol i n

det ai l .

PROBE_WAI T 1 second ( i ni t i al r andom del ay)


PROBE_MI N 1 second ( mi ni mum del ay unt i l r epeat ed probe)

PROBE_MAX 2 seconds ( maxi mum del ay unt i l r epeated probe)

ANNOUNCE_WAI T 2 seconds ( del ay bef or e announci ng)

ANNOUNCE_NUM 2 ( number of announcement packet s)

ANNOUNCE_I NTERVAL 2 seconds ( t i me bet ween announcement packet s)

MAX_CONFLI CTS 10 ( max conf l i ct s bef ore r ate l i mi t i ng)

RATE_LI MI T_I NTERVAL 60 seconds ( del ay bet ween successi ve at t empts)

DEFEND_I NTERVAL 10 seconds (mi ni mum i nterval bet ween def ensi ve

ARPs) .

1. 2 Rel at i onshi p to RFC 826

Thi s document does not modi f y any of t he prot ocol r ul es i n RFC 826.

I t does not modi f y t he packet f ormat , or t he meani ng of any

of t he f i el ds. The exi st i ng r ul es f or " Packet Gener at i on" and

"Packet Recept i on" st i l l appl y exact l y as speci f i ed i n RFC 826.




Thi s document expands on RFC 826 by speci f yi ng:

( 1) t hat a speci f i c ARP Request shoul d be gener ated when an i nter f ace

i s conf i gur ed, t o di scover i f t he addr ess i s al r eady i n use, and

( 2) an addi t i onal t r i vi al t est t hat shoul d be per f or med on each

r ecei ved ARP packet , t o f aci l i t at e passi ve ongoi ng conf l i ct

det ect i on. Thi s addi t i onal t est cr eat es no addi t i onal packet

overhead on t he network ( no addi t i onal packet s are sent ) and

negl i gi bl e addi t i onal CPU bur den on host s, si nce ever y host

i mpl ement i ng ARP i s *al r eady* r equi r ed t o pr ocess ever y recei ved

ARP packet accor di ng to the "Packet Recept i on" r ul es speci f i ed i n

RFC 826. These r ul es al r eady i ncl ude checki ng t o see i f t he

sender I P addr ess of t he ARP packet appears i n any of t he ent r i es

i n t he host ' s ARP cache; t he addi t i onal t est i s si mpl y t o check

t o see i f t he sender I P addr ess i s t he host ' s *own* I P addr ess,

pot ent i al l y as l i t t l e as a si ngl e addi t i onal machi ne i nstr ucti on

on many archi t ectures.

As al r eady speci f i ed i n RFC 826, an ARP Request packet ser ves t wo

f unct i ons, an asser t i on and a quest i on:

* Asser t i on:

The f i el ds "ar $sha" ( Sender Har dwar e Address) and "ar $spa" ( Sender

Prot ocol Addr ess) t oget her ser ve as an assert i on of a f act , t hat

t he st ated Protocol Addr ess i s mapped to the st ated Hardware

Addr ess.

* Quest i on:

The f i el ds "ar $tha" ( Target Har dwar e Address, zer o) and "ar $tpa"

( Tar get Pr ot ocol Addr ess) ser ve as a quest i on, aski ng, f or t he

st ated Protocol Addr ess, t o whi ch Hardware Addr ess i t i s mapped.

Thi s document cl ar i f i es what i t means t o have one wi t hout t he ot her .

1. 2. 1 Br oadcast Repl i es

I n some appl i cat i ons of I Pv4 Addr ess Conf l i ct Det ect i on ( ACD) , i t

may be advant ageous t o del i ver ARP Repl i es usi ng br oadcast i nst ead of




uni cast because t hi s al l ows addr ess conf l i ct s t o be det ect ed sooner

t han mi ght ot herwi se happen. For exampl e, "Dynami c Conf i gur at i on of

I Pv4 Li nk- Local Addr esses" [ RFC3927] uses ACD exact l y as speci f i ed

her e, but addi t i onal l y speci f i es t hat ARP Repl i es shoul d be sent

usi ng br oadcast , because i n t hat cont ext t he t r ade- of f of i ncr easedbr oadcast t r af f i c i n exchange f or i mpr oved r el i abi l i t y and

f aul t - t ol erance was deemed t o be an appropr i ate one. There may be

ot her f ut ur e speci f i cat i ons wher e t he same t r ade- of f i s appr opr i at e.

RFC 826 i mpl i es t hat r epl i es t o ARP Request s ar e usual l y del i ver ed

usi ng uni cast , but i t i s al so accept abl e t o del i ver ARP Repl i es usi ng

br oadcast . The "Packet Recept i on" r ul es i n RFC 826 speci f y t hat t he

cont ent of t he "ar $spa" f i el d shoul d be pr ocessed *bef or e* exami ni ng

t he "ar$op" f i el d, so any host t hat cor r ect l y i mpl ement s t he Packet

Recept i on al gor i t hm speci f i ed i n RFC 826 wi l l cor r ect l y handl e ARP

Repl i es del i ver ed vi a l i nk-l ayer br oadcast .

1. 3. Appl i cabi l i ty

Thi s speci f i cat i on appl i es t o al l I EEE 802 Local Ar ea Net wor ks ( LANs)

[ 802] , i ncl udi ng Et her net [ 802. 3] , Token- Ri ng [802. 5] and I EEE 802. 11

wi r el ess LANs [ 802. 11] , as wel l as t o ot her l i nk- l ayer t echnol ogi es

t hat oper at e at dat a rat es of at l east 1 Mbps, have a round- t r i p

l atency of at most one second, and use ARP [ RFC826] t o map f r om I P

addresses t o l i nk- l ayer hardware addr esses. Wher ever t hi s document

uses t he t er m " I EEE 802" , t he t ext appl i es equal l y t o any of t hese

net work t echnol ogi es.

Li nk- l ayer t echnol ogi es t hat suppor t ARP but oper at e at r at es bel ow

1 Mbps or l at enci es above one second wi l l st i l l wor k cor r ect l y wi t h

t hi s pr ot ocol , but mor e of t en may have t o handl e l at e conf l i ct s

det ected af t er t he Probi ng phase has compl eted. On t hese ki nds

of l i nk, i t may be desi r abl e t o speci f y di f f er ent val ues f or t he

f ol l owi ng par amet ers :

( a) PROBE_NUM, PROBE_MI N, and PROBE_MAX, t he number of , and i nt er val

bet ween, ARP pr obes, expl ai ned i n Sect i on 2. 1. 1.

( b) ANNOUNCE_NUM and ANNOUNCE_I NTERVAL, t he number of , and i nt er val

bet ween, ARP announcement s, expl ai ned i n Sect i on 2. 3.




( c) RATE_LI MI T_I NTERVAL and MAX_CONFLI CTS, cont r ol l i ng the maxi mum

r ate at whi ch addr ess cl ai mi ng may be at t empt ed, expl ai ned i n

Sect i on 2. 1. 1.

( d) DEFEND_I NTERVAL, t he t i me i nterval between conf l i ct i ng ARPs bel ow

whi ch a host MUST NOT at t empt t o def end i t s addr ess, expl ai ned i n

Sect i on 2. 4.

Li nk- l ayer t echnol ogi es t hat do not support ARP may be abl e t o use

ot her t echni ques f or det er mi ni ng whet her a par t i cul ar I P addr ess i s

cur r ent l y i n use. However , i mpl ement i ng Addr ess Conf l i ct Detect i on

f or such networ ks i s out si de t he scope of t hi s document .

For t he pr ot ocol speci f i ed i n thi s document t o be ef f ect i ve,

i t i s not necessar y that ever y host on t he l i nk i mpl ement s i t .

For a gi ven host i mpl ement i ng t hi s speci f i cat i on t o be pr ot ect ed

agai nst acci dent al addr ess conf l i cts, al l t hat i s r equi r ed i s t hat

t he peer s on t he same l i nk cor r ect l y i mpl ement t he ARP pr otocol as

gi ven i n RFC 826. To be speci f i c, when a peer host r ecei ves an ARP

Request wher e t he Tar get Protocol Addr ess of t he ARP Request matches

( one of ) t hat host ' s I P addr ess( es) conf i gur ed on t hat i nt er f ace,

t hen as l ong as i t pr oper l y responds wi t h a cor r ect l y- f or mat t ed ARP

Repl y, t he quer yi ng host wi l l be abl e t o det ect t hat t he addr ess i s

al r eady i n use.

The speci f i cat i ons i n t hi s document al l ow host s t o detect conf l i ct s

bet ween two host s usi ng t he same addr ess on t he same physi cal l i nk.

ACD does not det ect conf l i ct s bet ween t wo host s usi ng t he same

addr ess on di f f er ent physi cal l i nks, and i ndeed i t shoul d not .

For exampl e, t he addr ess 10. 0. 0. 1 [ RFC1918] i s i n use by count l ess

devi ces on count l ess pr i vat e net wor ks t hr oughout t he wor l d, and t hi s

i s not a conf l i ct, because t hey ar e on di f f er ent l i nks. I t woul d

onl y be a conf l i ct i f t wo such devi ces were t o be connect ed t o t he

same l i nk, and when t hi s happens ( as i t somet i mes does) , t hi s i s a

per f ect exampl e of a si t uat i on wher e ACD i s ext r emel y usef ul t o

det ect and r epor t ( and/ or aut omat i cal l y cor r ect ) t hi s er r or .

For t he pur poses of t hi s document , a set of host s i s consi der ed to

be "on t he same l i nk" i f :




- when any host A f r om t hat set sends a packet t o any other host B

i n t hat set , usi ng uni cast , mul t i cast , or br oadcast , t he ent i r e

l i nk- l ayer packet payl oad ar r i ves unmodi f i ed, and

- a br oadcast sent over t hat l i nk by any host f r om t hat set of host scan be recei ved by ever y ot her host i n that set

The l i nk- l ayer *header* may be modi f i ed, such as i n Token Ri ng Sour ce

Rout i ng [ 802. 5] , but not t he l i nk- l ayer *payl oad*. I n par t i cul ar , i f

any devi ce f orwar di ng a packet modi f i es any par t of t he I P header or

I P payl oad then the packet i s no l onger consi dered t o be on the same

l i nk. Thi s means t hat t he packet may pass t hrough devi ces such as

r epeat er s, br i dges, hubs or swi t ches and st i l l be consi der ed t o be on

t he same l i nk f or t he pur pose of t hi s document , but not t hr ough a

devi ce such as an I P rout er t hat decrement s t he TTL or other wi se

modi f i es the I P header .

2. Addr ess Pr obi ng, Announci ng, Conf l i ct Det ect i on and Def ense

Thi s sect i on descr i bes i ni t i al probi ng t o saf el y deter mi ne whether an

addr ess i s al r eady i n use, announci ng t he chosen addr ess, ongoi ng

conf l i ct checki ng, and opt i onal use of br oadcast ARP Repl i es t o

pr ovi de f ast er conf l i ct det ecti on.

2. 1 Pr obi ng an Address

Bef ore begi nni ng t o use an I Pv4 address ( whet her r ecei ved f r ommanual

conf i gurat i on, DHCP, or some other means) , a host i mpl ement i ng t hi s

speci f i cat i on MUST test t o see i f t he addr ess i s al r eady i n use, by

broadcast i ng ARP Probe packets. Thi s al so appl i es when when a

net wor k i nt er f ace t r ansi t i ons f r om an i nacti ve to an acti ve st at e,

when a comput er awakes f r om sl eep, when a l i nk- st ate change si gnal s

t hat an Ether net cabl e has been connect ed, when an 802. 11 wi r el ess

i nt er f ace associ at es wi t h a new base st at i on, or any other change i n

connect i vi t y wher e a host becomes act i vel y connect ed t o a l ogi cal

l i nk.

A host MUST NOT perf or m t hi s check peri odi cal l y as a mat t er of

cour se. Thi s woul d be a wast e of net work bandwi dth, and i s

unnecessary due t o t he abi l i t y of host s t o passi vel y di scover

conf l i cts, as descri bed i n Secti on 2. 4.




2. 1. 1. Pr obe Det ai l s

A host pr obes t o see i f an addr ess i s al r eady i n use by br oadcast i ng

an ARP Request f or t he desi r ed addr ess. The cl i ent MUST f i l l i n t he' sender har dware address' f i el d of t he ARP Request wi t h t he hardware

addr ess of t he i nt er f ace t hr ough whi ch i t i s sendi ng t he packet . The

' sender I P addr ess' f i el d MUST be set t o al l zer oes, t o avoi d

pol l ut i ng ARP caches i n ot her hosts on t he same l i nk i n t he case

where the address t urns out t o be al r eady i n use by anot her host .

The ' t ar get hardwar e addr ess ' f i el d i s i gnor ed and SHOULD be set t o

al l zer oes. The ' t ar get I P addr ess' f i el d MUST be set t o t he addr ess

bei ng pr obed. An ARP Request const r uct ed t hi s way wi t h an al l - zero

' sender I P addr ess' i s r ef er r ed t o as an "ARP Pr obe".

When r eady t o begi n pr obi ng, t he host shoul d t hen wai t f or a random

t i me i nt erval sel ect ed uni f orml y i n the range zer o to PROBE_WAI T

seconds, and shoul d t hen send PROBE_NUM probe packet s, each of t hese

probe packet s spaced r andoml y, PROBE_MI N t o PROBE_MAX seconds apar t .

Thi s i ni t i al r andom del ay hel ps ensur e t hat a l ar ge number of host s

power ed on at t he same t i me do not al l send t hei r i ni t i al pr obe

packet s s i mul t aneousl y.

I f dur i ng t hi s per i od, f r om t he begi nni ng of t he pr obi ng pr ocess

unt i l ANNOUNCE_WAI T seconds af t er t he l ast pr obe packet i s sent , t he

host r ecei ves any ARP packet ( Request *or * Repl y) on t he i nt er f ace

where the pr obe i s bei ng per f ormed wher e the packet ' s ' sender I P

addr ess' i s t he addr ess bei ng pr obed f or, t hen t he host MUST t r eat

t hi s addr ess as bei ng i n use by some ot her host , and shoul d i ndi cat e

t o t he conf i gur i ng agent ( human operat or, DHCP server , etc. ) t hat t he

proposed addr ess i s not accept abl e.

I n addi t i on, i f dur i ng t hi s per i od t he host r ecei ves any ARP Pr obe

wher e t he packet ' s ' t ar get I P addr ess' i s t he addr ess bei ng pr obed

f or , and t he packet ' s ' sender har dwar e addr ess' i s not t he har dwar e

addr ess of t he i nt er f ace t he host i s at t empt i ng t o conf i gur e, t hen

t he host MUST si mi l ar l y tr eat t hi s as an addr ess conf l i ct and si gnal

an er r or t o t he conf i gur i ng agent as above. Thi s can occur i f t wo

( or mor e) host s have, f or what ever r eason, been i nadver t ent l y

conf i gur ed wi t h t he same addr ess, and bot h ar e si mul t aneousl y i n t he

pr ocess of pr obi ng t hat addr ess t o see i f i t can saf el y be used.




NOTE: The check t hat t he packet ' s ' sender har dware address' i s not

t he har dwar e addr ess of any of t he host ' s i nt er f aces i s i mpor t ant .

Some ki nds of Et hernet hub ( of t en cal l ed a "buf f ered r epeater" ) and

many wi r el ess access poi nt s may "r ebr oadcast " any r ecei ved br oadcastpacket s t o al l r eci pi ent s, i ncl udi ng t he or i gi nal sender i t sel f . For

t hi s r eason, t he pr ecaut i on descr i bed above i s necessar y to ensure

t hat a host i s not conf used when i t sees i t s own ARP packets echoed

back.

A host i mpl ement i ng thi s speci f i cat i on MUST t ake pr ecaut i ons t o l i mi t

t he rat e at whi ch i t pr obes f or new candi dat e addr esses: I f t he host

exper i ences MAX_CONFLI CTS or more addr ess conf l i ct s on a gi ven

i nt er f ace, t hen t he host MUST l i mi t t he r at e at whi ch i t pr obes f or

new addresses on t hi s i nter f ace t o no more than one per

RATE_LI MI T_I NTERVAL. Thi s i s t o pr event cat ast r ophi c ARP st or ms i n

pat hol ogi cal f ai l ur e cases, such as a def ect i ve DHCP ser ver t hat

r epeat edl y assi gns t he same addr ess t o every host t hat asks f or one.

Thi s r at e l i mi t i ng r ul e appl i es not onl y t o conf l i ct s experi enced

dur i ng t he i ni t i al pr obi ng phase, but al so t o conf l i cts exper i enced

l at er , as descr i bed i n Sect i on 2. 4 "Ongoi ng Addr ess Conf l i ct

Detect i on and Addr ess Def ense" .

I f , by ANNOUNCE_WAI T seconds af t er t he t r ansmi ssi on of t he l ast ARP

Probe no conf l i ct i ng ARP Repl y or ARP Pr obe has been r ecei ved, t hen

t he host has successf ul l y determi ned t hat t he desi r ed addr ess may be

used saf el y.

2. 2 Shor t er Ti meouts on Appropr i ate Network Technol ogi es

Network t echnol ogi es may emerge f or whi ch shor t er del ays are

appropr i ate t han t hose r equi r ed by t hi s document . A subsequent I ETF

publ i cat i on may be pr oduced pr ovi di ng gui del i nes f or di f f er ent val ues

f or PROBE_WAI T, PROBE_NUM, PROBE_MI N and PROBE_MAX on t hose

t echnol ogi es.

I f t he si t uat i on ar i ses wher e di f f er ent host s on a l i nk ar e usi ng

di f f erent t i mi ng par amet er s, t hi s does not cause any pr obl ems. Thi s

pr otocol i s not dependent on al l host s on a l i nk i mpl ement i ng t he

same ver si on of t he pr ot ocol ; i ndeed, t hi s prot ocol i s not dependent

on al l host s on a l i nk i mpl ement i ng t he pr ot ocol at al l . Al l t hat i s




r equi r ed i s t hat al l host s i mpl ement ARP as speci f i ed i n RFC 826, and

cor r ect l y answer ARP Request s they r ecei ve. I n t he si t uat i on wher e

di f f er ent host s ar e usi ng di f f er ent t i mi ng par amet er s, al l t hat wi l l

happen i s t hat some host s wi l l conf i gur e t hei r i nt er f aces qui cker

t han ot her s. I n t he unl i kel y event t hat an addr ess conf l i ct i s notdet ect ed dur i ng t he addr ess pr obi ng phase, t he conf l i ct wi l l st i l l be

det ect ed by t he Ongoi ng Addr ess Conf l i ct Detect i on descr i bed bel ow i n

Sect i on 2. 4.

2. 3 Announci ng an Addr ess

Havi ng probed t o det ermi ne t hat a desi r ed address may be used saf el y,

a host i mpl ement i ng thi s speci f i cat i on MUST t hen announce that i t

i s commenci ng to use t hi s address by broadcast i ng ANNOUNCE_NUM ARP

announcement s, spaced ANNOUNCE_I NTERVAL seconds apar t . An ARP

announcement i s i dent i cal t o t he ARP Pr obe descr i bed above, except

t hat now t he sender and t arget I P addresses ar e bot h set t o t he

host ' s newl y sel ected I Pv4 address. The purpose of t hese ARP

announcement s i s t o make sur e that other host s on t he l i nk do not

have st al e ARP cache ent r i es l ef t over f r om some ot her host t hat may

previ ousl y have been usi ng t he same address. The host may begi n

l egi t i mat el y usi ng t he I P addr ess i mmedi at el y af t er sendi ng t he f i r st

of t he two ARP announcement s, and the sendi ng of t he second ARP

announcement may be compl et ed asynchronousl y, concurr ent wi t h ot her

net worki ng operat i ons t he host may wi sh t o per f orm.

2. 4 Ongoi ng Addr ess Conf l i ct Detect i on and Address Def ense

Addr ess conf l i ct det ecti on i s not l i mi t ed t o onl y t he t i me of i ni t i al

i nt er f ace conf i gur at i on, when a host i s sendi ng ARP pr obes. Addr ess

conf l i ct det ecti on i s an ongoi ng pr ocess t hat i s i n ef f ect f or as

l ong as a host i s usi ng an addr ess. At any t i me, i f a host r ecei ves

an ARP packet ( Request *or * Repl y) wher e the ' sender I P addr ess' i s

( one of ) t he host ' s own I P addr ess( es) conf i gur ed on t hat i nt er f ace,

but t he ' sender hardware address' does not match any of t he host ' s

own i nt er f ace addr esses, t hen t hi s i s a conf l i ct i ng ARP packet ,

i ndi cat i ng some ot her host al so t hi nks i t i s val i dl y usi ng t hi s

addr ess. To r esol ve t he addr ess conf l i ct , a host MUST r espond t o a

conf l i ct i ng ARP packet as descri bed i n ei t her ( a) , ( b) or ( c) bel ow:

( a) Upon recei vi ng a conf l i ct i ng ARP packet , a host MAY el ect t o




i mmedi atel y cease usi ng t he addr ess, and si gnal an er r or t o the

conf i gur i ng agent as descr i bed above, or

( b) I f a host cur r ent l y has act i ve TCP connect i ons or ot her r easons

t o pr ef er t o keep the same I Pv4 address, and i t has not seen anyother conf l i ct i ng ARP packet s wi t hi n t he l ast DEFEND_I NTERVAL

seconds, t hen i t MAY el ect t o at t empt t o def end i t s addr ess by

r ecor di ng t he t i me t hat t he conf l i ct i ng ARP packet was r ecei ved, and

t hen br oadcast i ng one si ngl e ARP announcement , gi vi ng i t s own I P and

har dware addresses as the sender addr esses of t he ARP. Havi ng done

t hi s, t he host can t hen cont i nue to use t he addr ess normal l y wi t hout

any f ur t her speci al acti on. However , i f t hi s i s not t he f i r st

conf l i ct i ng ARP packet t he host has seen, and the t i me recor ded f or

t he pr evi ous conf l i ct i ng ARP packet i s r ecent , wi t hi n DEFEND_I NTERVAL

seconds, t hen t he host MUST i mmedi atel y cease usi ng t hi s address and

si gnal an er r or t o t he conf i gur i ng agent as descr i bed above. Thi s i s

necessary t o ensure t hat t wo host s do not get st uck i n an endl ess

l oop wi t h bot h host s t r yi ng t o def end t he same addr ess.

( c) I f a host has been conf i gur ed such t hat i t shoul d not gi ve up i t s

address under any ci r cumst ances ( perhaps because i t i s t he ki nd of

devi ce t hat needs t o have a wel l - known st abl e I P addr ess, such as a

l i nk' s def aul t r out er , or a DNS ser ver ) t hen i t MAY el ect t o def end

i t s addr ess i ndef i ni t el y. I f such a host r ecei ves a conf l i cti ng ARP

packet , t hen i t shoul d t ake appr opr i at e st eps t o l og usef ul

i nf or mat i on such as sour ce Et her net addr ess f r omt he ARP packet , and

i nf or m an admi ni st r ator of t he pr obl em. The number of such

not i f i cat i ons shoul d be appr opr i at el y cont r ol l ed t o pr event an

excessi ve number of er r or r eport s bei ng gener at ed. I f t he host has

not seen any ot her conf l i ct i ng ARP packet s r ecent l y wi t hi n t he l ast

DEFEND_I NTERVAL seconds t hen i t MUST r ecord t he t i me that t he

conf l i ct i ng ARP packet was r ecei ved, and t hen br oadcast one si ngl e

ARP announcement , gi vi ng i t s own I P and har dware addresses. Havi ng

done thi s, t he host can then cont i nue t o use t he addr ess nor mal l y

wi t hout any f ur t her speci al acti on. However , i f t hi s i s not t he

f i r st conf l i ct i ng ARP packet t he host has seen, and t he ti me recor ded

f or t he pr evi ous conf l i ct i ng ARP packet i s wi t hi n DEFEND_I NTERVAL

seconds t hen t he host MUST NOT send anot her def ensi ve ARP

announcement . Thi s i s necessar y t o ensure t hat t wo mi sconf i gured

host s do not get s t uck i n an endl ess l oop f l oodi ng t he net work wi t h

br oadcast t r af f i c whi l e t hey bot h t r y t o def end t he same addr ess.




A host wi shi ng to pr ovi de rel i abl e networ k oper at i on MUST respond to

conf l i ct i ng ARP packet s as descr i bed i n ( a) , ( b) or ( c) above.I gnor i ng conf l i ct i ng ARP packet s r esul t s i n seemi ngl y random net wor k

f ai l ur es whi ch can be hard t o di agnose and ver y f r ust r at i ng f or human

users.

For ced addr ess r econf i gur at i on may be di sr upt i ve, causi ng TCP

connect i ons t o be br oken. However , such di sr upt i ons shoul d be

exceedi ngl y r ar e, and i f i nadver t ent addr ess dupl i cat i on happens,

t hen di sr upt i on of communi cat i on i s i nevi t abl e. I t i s not possi bl e

f or t wo di f f erent host s usi ng t he same I P address on t he same network

t o oper at e r el i abl y.

Bef ore abandoni ng an address due t o a conf l i ct , host s SHOULD act i vel y

at t empt t o r eset any exi st i ng connect i ons usi ng t hat addr ess. Thi s

mi t i gat es some secur i t y t hr eat s posed by addr ess r econf i gur at i on, as

di scussed i n Sect i on 3.

For most cl i ent machi nes t hat do not need a f i xed I P addr ess,

i mmedi atel y r equest i ng t he conf i gur i ng agent ( human user , DHCP

cl i ent , et c. ) t o conf i gur e a new addr ess as soon as t he conf l i ct i s

det ect ed i s t he best way t o rest or e usef ul communi cat i on as qui ckl y

as possi bl e. The mechani sm descr i bed above of broadcast i ng a si ngl e

ARP announcement t o def end the address mi t i gat es t he probl em

somewhat , by hel pi ng t o i mprove t he chance t hat one of t he t wo

conf l i ct i ng host s may be abl e to r et ai n i t s addr ess.

2. 5 Br oadcast ARP Repl i es

I n a car ef ul l y- r un net wor k wi t h manual l y- assi gned addr esses, or

a net work wi t h a r el i abl e DHCP ser ver and r el i abl e DHCP cl i ent s,

addr ess conf l i ct s shoul d occur onl y i n r ar e f ai l ur e scenar i os,

so t he passi ve moni t or i ng descr i bed above i n Sect i on 2. 4 i s adequate.

I f t wo host s are usi ng t he same I P addr ess, t hen sooner or l at er one

or ot her host wi l l br oadcast an ARP Request , whi ch t he other wi l l

see, al l owi ng the conf l i ct t o be det ect ed and consequent l y r esol ved.

I t i s possi bl e however , t hat a conf l i ct i ng conf i gur at i on may per si st




f or a shor t t i me bef or e i t i s detect ed. Suppose t hat t wo host s A and

B have been i nadver t ent l y assi gned t he same I P address X. Suppose

f ur t her t hat at t he t i me they were both probi ng t o determi ne whether

t he address coul d saf el y be used, t he communi cat i on l i nk between them

was non- f unct i onal f or some reason, so nei t her det ect ed the conf l i ctat i nt erf ace- conf i gur at i on t i me. Suppose now t hat t he communi cat i on

l i nk i s r est ored, and a t hi r d host C br oadcast s an ARP Request f or

addr ess X. Unawar e of any conf l i ct , both host s A and B wi l l send

uni cast ARP Repl i es t o host C. Host C wi l l see bot h Repl i es, and may

be a l i t t l e conf used, but nei t her host A nor B wi l l see t he ot her ' s

Repl y, and nei t her wi l l i mmedi at el y det ect t hat t her e i s a conf l i ct

t o be r esol ved. Host s A and B wi l l cont i nue t o be unaware of t he

conf l i ct unt i l one or ot her broadcast s an ARP Request of t hei r own.

I f qui cker conf l i ct det ect i on i s desi r ed, t hi s may be achi eved by

havi ng host s send ARP Repl i es usi ng l i nk- l evel br oadcast , i nst ead of

sendi ng onl y ARP Request s vi a br oadcast , and Repl i es vi a uni cast .

Thi s i s NOT RECOMMENDED f or gener al use, but ot her speci f i cat i ons

bui l di ng on I Pv4 ACD may choose t o speci f y br oadcast ARP Repl i es i f

appr opr i ate. For exampl e, "Dynami c Conf i gur at i on of I Pv4 Li nk- Local

Addresses" [ RFC3927] speci f i es br oadcast ARP Repl i es because i n t hat

cont ext , det ect i on of addr ess conf l i ct s usi ng I Pv4 ACD i s not mer el y

a backup pr ecaut i on t o det ect f ai l ur es of some ot her conf i gur at i on

mechani sm; detect i on of addr ess conf l i ct s usi ng I Pv4 ACD i s t he sol e

conf i gurat i on mechani sm.

Sendi ng ARP Repl i es usi ng br oadcast does i ncr ease br oadcast t r af f i c,

but i n t he wors t case by no more t han a f act or of t wo. I n t he

t r adi t i onal usage of ARP, a uni cast ARP Repl y onl y occur s i n r esponse

t o a br oadcast ARP Request , so sendi ng t hese vi a br oadcast i nst ead

means t hat we generate at most one br oadcast Repl y i n response t o

each exi st i ng br oadcast Request . On many net works, ARP t r af f i c i s

such an i nsi gni f i cant pr opor t i on of t he t ot al t r af f i c t hat doubl i ng

i t makes no pr act i cal di f f er ence. However, t hi s may not be t r ue of

al l net works, so broadcast ARP Repl i es SHOULD NOT be used

uni ver sal l y. Br oadcast ARP Repl i es shoul d be used where t he benef i t

of f ast er conf l i ct det ect i on out wei ghs t he cost of i ncreased

br oadcast t r af f i c and i ncr eased packet pr ocessi ng l oad on the

par t i ci pant net wor k host s.

3. Secur i t y Consi der at i ons




I Pv4 Addr ess Conf l i ct Detect i on ( ACD) i s based on ARP [ RFC826] and

i nher i t s t he secur i t y vul ner abi l i t i es of t hi s pr ot ocol . A mal i ci ous

host may send f r audul ent ARP packet s on t he net work, i nt er f eri ng wi t h

t he cor r ect oper at i on of ot her host s. For exampl e, i t i s easy f or ahost t o answer al l ARP Request s wi t h Repl i es gi vi ng i t s own hardware

address, t her eby cl ai mi ng ownershi p of every addr ess on t he network.

Thi s speci f i cat i on makes t hi s exi st i ng ARP vul nerabi l i t y no wor se,

and i n some ways makes i t bet t er : I nst ead of f ai l i ng si l ent l y wi t h no

i ndi cat i on why, host s i mpl ement i ng t hi s speci f i cat i on ei t her at t empt

t o r econf i gur e aut omat i cal l y, or at l east i nf or m t he human user of

what i s happeni ng.

I f a host wi l l i ngl y sel ect s a new addr ess i n r esponse to an ARP

conf l i ct, as descr i bed i n Secti on 2. 4 subsecti on ( a) , t hi s

pot ent i al l y makes i t easi er f or mal i ci ous at t acker s on t he same l i nk

t o hi j ack TCP connect i ons. Havi ng a host act i vel y r eset any exi st i ng

connect i ons bef or e abandoni ng an addr ess hel ps mi t i gat e t hi s r i sk.

4. Hi stori cal Not e

A wi del y- known, but i nef f ect i ve, dupl i cat e addr ess det ect i on

t echni que cal l ed "Gr atui t ous ARP" i s f ound i n many depl oyed syst ems

[ St e94] . What St evens descr i bes as Gr atui t ous ARP i s t he exact same

packet t hat t hi s document r ef ers t o by the more descr i pt i ve t erm "ARP

Announcement " . Thi s t r adi t i onal Gr atui t ous ARP i mpl ement at i on sends

onl y a si ngl e ARP Announcement when an i nt erf ace i s f i r st conf i gur ed.

The r esul t i s t hat t he vi ct i m ( t he exi st i ng addr ess hol der ) l ogs

an er r or , and the of f ender cont i nues oper at i on, of t en wi t hout even

det ect i ng any pr obl em. Both machi nes t hen t ypi cal l y pr oceed t o t r y

t o use t he same I P addr ess, and f ai l t o operat e pr oper l y because t hey

are each const ant l y r eset t i ng t he other ' s TCP connect i ons. The human

admi ni st r at or i s expect ed to not i ce t he l og message on the vi ct i m

machi ne and r epai r t he damage af t er t he f act . Typi cal l y t hi s has t o

be done by physi cal l y goi ng t o t he machi nes i n quest i on, si nce i n

t hi s st at e nei t her i s abl e to keep a TCP connect i on open f or l ong

enough t o do anyt hi ng usef ul over t he network.

The probl ems caused by t hi s i nef f ect i ve dupl i cat e addr ess detect i on

t echni que ar e i l l ust r at ed by t he f act t hat ( as of August 2004)




t he t op Googl e sear ch r esul t s f or t he phr ase "Gr atui t ous ARP" are

ar t i cl es descri bi ng how t o di sabl e i t .

However , i mpl ement er s of I Pv4 Addr ess Conf l i ct Detect i on shoul d be

awar e t hat , as of t hi s wr i t i ng, Gr at ui t ous ARP i s sti l l wi del ydepl oyed. The st eps descr i bed i n Sect i ons 2. 1 and 2. 4 of t hi s

document hel p make a host r obust agai nst mi sconf i gur at i on and address

conf l i ct s, even when t he other host i s *not * pl ayi ng by the same

r ul es.

5. Why are ARP Announcement s per f or med usi ng ARP Request packet s

and not ARP Repl y packet s?

Dur i ng I ETF del i ber at i on of I Pv4 Addr ess Conf l i ct Det ect i on f r om 2000

t o 2005, a quest i on t hat kept bei ng asked repeatedl y was, "Shoul dn' t

ARP Announcement s be per f ormed usi ng grat ui t ous ARP Repl y packet s?"

On t he f ace of i t , t hi s seems reasonabl e. A convent i onal ARP Repl y

i s an answer t o a quest i on. I f i n f act no quest i on had been asked,

t hen i t woul d be r easonabl e t o descr i be such a r epl y as gr at ui t ous.

Thi s descr i pt i on woul d seem t o appl y per f ect l y t o an ARP

Announcement : an answer t o an i mpl i ed quest i on t hat i n f act no one

asked.

However r easonabl e t hi s may seem i n pr i nci pl e, t her e ar e two reasons

why i n pr act i ce ARP Request packet s are t he bet t er choi ce. One i s

hi st or i cal pr ecedent , and t he ot her i s pr acti cal i t y.

The hi st or i cal precedent i s t hat , as descr i bed above i n Sect i on 4,

Gr atui t ous ARP i s descr i bed i n St evens Networ ki ng [ St e94] as usi ng

ARP Request packet s. BSD Uni x, Wi ndows, Mac OS 9, Mac OS X, et c.

al l use ARP Request packet s as descr i bed i n St evens. At t hi s st age,

t r yi ng t o mandate that t hey al l swi t ch t o usi ng ARP Repl y packet s

woul d be f ut i l e.

The pract i cal r eason i s t hat ARP Request packet s ar e mor e l i kel y t o

work cor r ect l y wi t h more exi st i ng ARP i mpl ement at i ons, some of whi ch

may not i mpl ement RFC 826 corr ect l y. The Packet Recept i on r ul es i n

RFC 826 st ate t hat t he opcode i s t he l ast t hi ng to check i n packet

pr ocessi ng, so i t r eal l y shoul dn' t mat t er , but t her e may be

"cr eat i ve" i mpl ement at i ons t hat have di f f er ent packet pr ocessi ng

dependi ng on t he ar$op f i el d, and t here are sever al r easons why t hese




are mor e l i kel y t o accept gr at ui t ous ARP Request s t han gr atui t ous ARP

Repl i es:

* An i ncor r ect ARP i mpl ement at i on may expect t hat ARP Repl i es are

onl y sent vi a uni cast . RFC 826 does not say t hi s, but an i ncor r ecti mpl ement at i on may assume i t , and the "pri nci pl e of l east sur pr i se"

di ct ates t hat wher e ther e ar e two or more ways t o sol ve a

net worki ng pr obl em t hat ar e ot her wi se equal l y good, t he one wi t h

t he f ewest unusual pr oper t i es i s t he one l i kel y t o have t he f ewest

i nt er oper abi l i t y pr obl ems wi t h exi st i ng i mpl ement at i ons. An ARP

Announcement needs t o br oadcast i nf ormat i on t o al l host s on t he

l i nk. Si nce ARP Request packets ar e al ways br oadcast , and ARP

Repl y packets are not , r ecei vi ng an ARP Request packet vi a

br oadcast i s l ess surpr i si ng t han r ecei vi ng an ARP Repl y packet vi a

broadcast .

* An i ncor r ect ARP i mpl ement at i on may expect t hat ARP Repl i es are

onl y r ecei ved i n response t o ARP Request s t hat have been i ssued

r ecent l y by t hat i mpl ement at i on. Unexpect ed unsol i ci t ed Repl i es

may be i gnor ed.

* An i ncor r ect ARP i mpl ement at i on may i gnore ARP Repl i es wher e

ar$t ha doesn' t match i t s har dware address.

* An i ncor r ect ARP i mpl ement at i on may i gnore ARP Repl i es wher e

ar$t pa doesn' t mat ch i t s I P addr ess.

I n summary, t her e ar e more ways t hat an i ncor r ect ARP i mpl ement at i on

mi ght pl ausi bl y rej ect an ARP Repl y ( whi ch usual l y occur s as a resul t

of bei ng sol i ci t ed by the cl i ent ) t han an ARP Request ( whi ch i s

al r eady expect ed t o occur unsol i ci t ed) .

6. I ANA Consi der at i ons

Thi s speci f i cat i on does not r equest t he cr eat i on of any new paramet er

r egi st r i es, nor does i t r equi r e any ot her I ANA assi gnment s.

7. Acknowl edgments

Thi s document ar ose as a r esul t of di scussi ons on l i nk- l ocal

addressi ng, where i t was not cl ear t o many r eader s whi ch el ement s of




l i nk- l ocal addr ess management wer e speci f i c t o that par t i cul ar

pr obl em, and whi ch el ement s were generi c and appl i cabl e t o al l I Pv4

address conf i gurat i on mechani sms. The f ol l owi ng peopl e made val uabl e

comment s i n the cour se of t hat work and/ or t he subsequent edi t i ng

of t hi s document : Bernar d Aboba, Randy Bush, J i m Busse, J amesCar l son, Al an Cox, Pavani Di wanj i , Ral ph Dr oms, Donal d East l ake 3r d,

Al ex El der , Pet er For d, Spencer Gi acal one, J osh Gr aessl ey, Er i k

Gut t man, Myron Hat t i g, Hugh Hol brook, Ri char d J ohnson, Ki m Yong- Woon,

Marc Kr ochmal , Rod Lopez, Sat i sh Mundra, Thomas Nar t en, Er i k

Nordmark, Howard Ri denour, Pekka Savol a, Dani el Seni e, Di eter

Si egmund, Val ery Smysl ov and Ryan Trol l .

8. Copyr i ght Not i ce

Copyri ght ( C) The I nt er net Soci et y ( 2005) .

Thi s document i s subj ect t o t he r i ghts, l i censes and r est r i ct i ons

cont ai ned i n BCP 78, and except as set f ort h t her ei n, t he aut hor s

r et ai n al l t hei r r i ght s. For t he pur poses of t hi s document ,

t he t er m "BCP 78" r ef er s excl usi vel y to RFC 3978, " I ETF Ri ght s

i n Cont r i but i ons" , publ i shed Mar ch 2005.

Thi s document and t he i nf or mat i on cont ai ned herei n are provi ded on an

"AS I S" basi s and THE CONTRI BUTOR, THE ORGANI ZATI ON HE/ SHE REPRESENTS

OR I S SPONSORED BY ( I F ANY) , THE I NTERNET SOCI ETY AND THE I NTERNET

ENGI NEERI NG TASK FORCE DI SCLAI M ALL WARRANTI ES, EXPRESS OR I MPLI ED,

I NCLUDI NG BUT NOT LI MI TED TO ANY WARRANTY THAT THE USE OF THE

I NFORMATI ON HEREI N WI LL NOT I NFRI NGE ANY RI GHTS OR ANY I MPLI ED

WARRANTI ES OF MERCHANTABI LI TY OR FI TNESS FOR A PARTI CULAR PURPOSE.

9. Normat i ve Ref erences

[ RFC826] D. Pl ummer, "An Et hernet Addr ess Resol ut i on Protocol - or -

Conver t i ng Network Addresses t o 48- bi t Et hernet Addr ess

f or Transmi ss i on on Ether net Hardware", STD 37, RFC 826,

November 1982.

[ RFC2119] S. Br adner , "Key wor ds f or use i n RFCs t o I ndi cat e

Requi r ement Level s" , RFC 2119, March 1997.




10. I nf ormat i ve Ref er ences

[ 802] I EEE St andar ds f or Local and Met r opol i t an Ar ea Networks:Over vi ew and Ar chi t ectur e, ANSI / I EEE St d 802, 1990.

[ 802. 3] I SO/ I EC 8802- 3 I nf or mat i on t echnol ogy - Tel ecommuni cat i ons

and i nf ormat i on exchange between syst ems - Local and

met r opol i t an ar ea networ ks - Common speci f i cat i ons - Par t

3: Car r i er Sense Mul t i pl e Access wi t h Col l i si on Det ect i on

( CSMA/ CD) Access Method and Physi cal Layer Speci f i cat i ons,

( al so ANSI / I EEE St d 802. 3- 1996) , 1996.

[ 802. 5] I SO/ I EC 8802- 5 I nf or mat i on t echnol ogy - Tel ecommuni cat i ons

and i nf ormat i on exchange between syst ems - Local and

met r opol i t an ar ea networ ks - Common speci f i cat i ons - Par t

5: Token r i ng access method and physi cal l ayer

speci f i cat i ons, ( al so ANSI / I EEE St d 802. 5- 1998) , 1998.

[ 802. 11] I nf or mat i on t echnol ogy - Tel ecommuni cat i ons and i nf ormat i on

exchange bet ween syst ems - Local and met r opol i t an area

net works - Speci f i c Requi r ement s Part 11: Wi r el ess LAN

Medi umAccess Cont r ol ( MAC) and Physi cal Layer ( PHY)

Speci f i cat i ons, I EEE St d. 802. 11- 1999, 1999.

[ RFC2131] R. Dr oms, "Dynami c Host Conf i gurat i on Protocol " ,

RFC 2131, Mar ch 1997.

[ RFC3927] S. Cheshi r e, B. Aboba, E. Gut t man,

"Dynami c Conf i gur at i on of I Pv4 Li nk- Local Addr esses" ,

RFC 3927, May 2005.

[ St e94] W. Stevens, " TCP/ I P I l l ust r at ed, Vol ume 1: The Prot ocol s" ,

Addi son- Wesl ey, 1994.

11. Aut hor ' s Addr ess

St uar t Cheshi r e

Appl e Computer , I nc.




1 I nf i ni t e Loop

Cuper t i no

Cal i f or ni a 95014

USA

Phone: +1 408 974 3207

EMai l : r f c@st uar t cheshi r e. or g

IAONA_SysAsp_IPv4ACD_v1.0

Documents

Transcript of IAONA_SysAsp_IPv4ACD_v1.0