インターネットパケットを送信したいと考える。起動したばかりであるためその情報を持たない。モジュールはそのインターネットパケットを破棄し、代わりに以下の内容のアドレス解決パケットを生成する。このパケットをケーブル上のすべてにブロードキャストする。マップする情報を(おそらく既存のエントリを置き換えて)入力する。(ブロードキャストではなく)直接送信する。送信する方法を知らない。マッピングを作り、パケットがリプライであることを知り、それを破棄する。パケットを送信しようとするとき、変換は成功し、パケットは(うまくいけば)到達するだろう。アドレス解決リクエストからの情報を覚えているため、それも成功するだろう。テーブルは劣化やタイムアウトを持つことが望ましいかもしれない。それらの実装は本プロトコルの範囲外である。ホストが移動する場合、そのアドレス変換テーブルは移動時にクリアされると考えられるため、そのホストから開始される接続は正しく動作するだろう。他のホストからそのホストへの接続は、古いアドレスが破棄されたことを知る特別な理由がない。ビットイーサネットアドレスは常にユニークかつ変化しないと予想されるため、変化しないはずである。経験から分かるように、ハードウェアまたはソフトウェアのエラーにより図らずも転送される不正なルーティング情報の危険性は常に存在する。永遠に存続することは許されるべきではない。接続開始の失敗は、ホストがダウンしているか古い変換がもはや有効でないということであるため、ホストが到達不能であることに基づいて情報を削除するようアドレス変換モジュールに通知するべきである。ホストからのパケットの受信は、そのホストへパケットを送信するために使用されるアドレス解決エントリ内のタイムアウトをリセットするべきだろう。適当な時間だけホストからパケットを受信しなかった場合、そのアドレス解決エントリは忘れられる。これは各入力パケットごとのテーブル読み取りのための余分なオーバーヘッドを引き起こす可能性がある。ハッシュまたはインデックスによってこれを高速化できるだろう。アドレス解決パケットを受信するための推奨されるアルゴリズムは、ホストが移動した場合の復旧に必要となる時間を減少させようと試みる。存在する場合、送信者のハードウェアアドレスが既存のエントリを上書きすることを思い出してほしい。そのため、ブロードキャストのリクエストがケーブル上の全ステーションに到達する完全なイーサネットでは、各ステーションが新しいハードウェアアドレスを取得するだろう。別の選択肢は、タイムアウトを実行するデーモンを持つというものである。適当な時間の経過後、デーモンはエントリの削除を検討する。アドレス解決パケットをテーブル内のイーサネットアドレスに直接送信する(必要なら数回だけ再送信する)。帰ってこなかった場合、そのエントリは削除される。イーサネット上のすべてのステーションの邪魔をしないように、このリクエストは直接送信される。単純にエントリを忘れることは、再取得されなければならない有用な情報を忘れることになるだろう。ホストは自分以外の情報を送信しないため、ホストのリブートはアドレスマッピングテーブルを最新化するだろう。不正な情報がマシンからマシンへと伝達されることはない。ビットイーサネットアドレスが変化したことを知らないマシン内だけに存在し得る。手動によるアドレスマッピングテーブルのリセット(またはクリア)で十分だろう。この問題が重要だと考えられるなら、明らかにさらなる検討が必要である。これは、あらゆる種類のアドレス解決プロトコルで起こる問題である。