История изменений

Раз вы упоминаете широковещательную передачу в контексте преобразования сетевого адреса в канальный, то имеете ввиду ARP протокол, поскольку Neighbour Discovery протокол использует многоадресную передачу.

О том, что это особенность Ethernet протокола, который обладает поддержкой широковещательной передачи, на канальном уровне, я должен с вами не согласиться. Возьмём для примера ATM или Frame Relay, они оба являются Non-Broadcast Multi-Access протоколами и могут использовать inverse ARP, что в ряде случаев приводит к тому, что они направляют inARP request через каждый PVC. При этом они не являются протоколами реализующими поддержку широковещательной передачи на канальном уровне, как Ethernet. Но, каждый узел получит ровно такой же ARP запрос, как и в случае Ethernet.

Более того, в стандарте IEEE 802.1/2/3 нет не слова о регистрации конфликтов IP адресов, этот уровень лежит вне поля компетенции Ethernet протокола. Поэтому IETF утвердила стандарты под номерами RFC 5257: IPv4 Address Conflict Detection, а так же RFC 4429: Optimistic Duplicate Address Detection (DAD) for IPv6, регламентирующие поведение узлов реализующих IP протокол в отношение проверки конфликтов сетевого уровня и их устранения.

Я не очень понял, что вы имели ввиду, когда говорили об ошибке, в том случае, если узел получает два ответа на ARP request. Где вы наблюдаете такое поведение? И самое главное, к чему ведёт такая ситуация на узле получателе?

- с точки зрения узла, получившего два ответа, нет не какой проблемы, он заменит первый пришедший ответ, вторым.

- с точки зрения узлов, которые дали такой ответ, проблемы тоже нет, поскольку они используют одноадресный ARP reply, иными словами оба узла буду считать, что второго узла не существует в сети с таким же адресом.

Если мы заглянем в ARP пакет, направляемый при выполнение процедуры IP DAD, воспользовавшись tcpdump, то увидим, что ARP request выглядит следующим образом:

nbytes: (ar$sha) Source MAC нашего узла mbytes: (ar$spa) 0.0.0.0 nbytes: (ar$tha) FF:FF:FF:FF:FF:FF (00:00:00:00:00:00) mbytes: (ar$tpa) IP адрес нашего узла

ar$tpa содержит наш собственный адрес, а ar$spa заполнен 0.0.0.0, что совершенно не характерно для классического ARP request, поэтому такой пакет называется ARP Probe.

Ответом на такой ARP Probe, будет ARP reply, на наш MAC адрес, указанный в поле ar$sha, что автоматически позволит нашему узлу узнать, что такой адрес уже занят.

Стандарт так же предписывает, выполнять следующую проверку, когда наш узел получает ARP request/reply, если ar$sha != MAC любого из наших интерфейсов, а ar$spa = IP любого из наших интерфейсов, то в сети существует конфликт IP адресов.

Но, получить ARP reply мы можем только в одном случае, если он был направлен не одноадресным кадром, а широковещательным. Лично я не встречал таких реализаций, а значит проверка сужается только до ARP request пакетов.

Исходя из выше изложенного я считаю, что ваше утверждение о том, что это особенность функционирования Ethernet сетей, ошибочна. Хотя в случае inverse ARP, ar$sha содержит Frame Relay DLCI или ATM VCI/VPI, который к тому же, ещё и меняется на каждом коммутаторе, тем не менее, это не ломает логику проверки, а только слегка меняет её.

Если мы получили кадр который содержит ar$sha = DLCI/VCI/VPI нашего PVC, а это всегда будет правдой, наш интерфейс заменяет ar$sha кадра при получение на собственный и ar$spa = IP нашего любого интерфейса, то в сети существует конфликт IP адресов.

Раз вы упоминаете широковещательную передачу в контексте преобразования сетевого адреса в канальный, то имеете ввиду ARP протокол, поскольку Neighbour Discovery протокол использует многоадресную передачу.

О том, что это особенность Ethernet протокола, который обладает поддержкой широковещательной передачи, на канальном уровне, я должен с вами не согласиться. Возьмём для примера ATM или Frame Relay, они оба являются Non-Broadcast Multi-Access протоколами и могут использовать inverse ARP, что в ряде случаев приводит к тому, что они направляют inARP request через каждый PVC. При этом они не являются протоколами реализующими поддержку широковещательной передачи на канальном уровне, как Ethernet. Но, каждый узел получит ровно такой же ARP запрос, как и в случае Ethernet.

Более того, в стандарте IEEE 802.1/2/3 нет не слова о регистрации конфликтов IP адресов, этот уровень лежит вне поля компетенции Ethernet протокола. Поэтому IETF утвердила стандарты под номерами RFC 5257: IPv4 Address Conflict Detection, а так же RFC 4429: Optimistic Duplicate Address Detection (DAD) for IPv6, регламентирующие поведение узлов реализующих IP протокол в отношение проверки конфликтов сетевого уровня и их устранения.

Я не очень понял, что вы имели ввиду, когда говорили об ошибке, в том случае, если узел получает два ответа на ARP request. Где вы наблюдаете такое поведение? И самое главное, к чему ведёт такая ситуация на узле получателе?

- с точки зрения узла, получившего два ответа, нет не какой проблемы, он заменит первый пришедший ответ, вторым.

- с точки зрения узлов, которые дали такой ответ, проблемы тоже нет, поскольку они используют одноадресный ARP reply, иными словами оба узла буду считать, что второго узла не существует в сети с таким же адресом.

Если мы заглянем в ARP пакет, направляемый при выполнение процедуры IP DAD, воспользовавшись tcpdump, то увидим, что ARP request выглядит следующим образом:

nbytes: (ar$sha) Source MAC нашего узла mbytes: (ar$spa) 0.0.0.0 nbytes: (ar$tha) FF:FF:FF:FF:FF:FF (00:00:00:00:00:00) mbytes: (ar$tpa) IP адрес нашего узла

ar$tpa содержит нас собственный адрес, а ar$spa заполнен 0.0.0.0, что совершенно не характерно для классического ARP request, поэтому такой пакет называется ARP Probe.

Ответом на такой ARP Probe, будет ARP reply, на наш MAC адрес, указанный в поле ar$sha, что автоматически позволит нашему узлу узнать, что такой адрес уже занят.

Стандарт так же предписывает, выполнять следующую проверку, когда наш узел получает ARP request/reply, если ar$sha != MAC любого из наших интерфейсов, а ar$spa = IP любого из наших интерфейсов, то в сети существует конфликт IP адресов.

Но, получить ARP reply мы можем только в одном случае, если он был направлен не одноадресным кадром, а широковещательным. Лично я не встречал таких реализаций, а значит проверка сужается только до ARP request пакетов.

Исходя из выше изложенного я считаю, что ваше утверждение о том, что это особенность функционирования Ethernet сетей, ошибочна. Хотя в случае inverse ARP, ar$sha содержит Frame Relay DLCI или ATM VCI/VPI, который к тому же, ещё и меняется на каждом коммутаторе, тем не менее, это не ломает логику проверки, а только слегка меняет её.

Если мы получили кадр который содержит ar$sha = DLCI/VCI/VPI нашего PVC, а это всегда будет правдой, наш интерфейс заменяет ar$sha кадра при получение на собственный и ar$spa = IP нашего любого интерфейса, то в сети существует конфликт IP адресов.

Раз вы упоминаете широковещательную передачу в контексте преобразования сетевого адреса в канальный, то имеете ввиду ARP протокол, поскольку Neighbour Discovery протокол использует многоадресную передачу.

О том, что это особенность Ethernet протокола, который обладает поддержкой широковещательной передачи, на канальном уровне, я должен с вами не согласиться. Возьмём для примера ATM или Frame Relay, они оба являются Non-Broadcast Multi-Access протоколами и могут использовать inverse ARP, что в ряде случаев приводит к тому, что они направляют inARP request через каждый PVC. При этом они не являются протоколами реализующими поддержку широковещательной передачи на канальном уровне, как Ethernet. Но, каждый узел получит ровно такой же ARP запрос, как и в случае Ethernet.

Более того, в стандарте IEEE 802.1/2/3 нет не слова о регистрации конфликтов IP адресов, этот уровень лежит вне поля компетенции Ethernet протокола. Поэтому IETF утвердила стандарты под номерами RFC 5257: IPv4 Address Conflict Detection, а так же RFC 4429: Optimistic Duplicate Address Detection (DAD) for IPv6, регламентирующие поведение узлов реализующих IP протокол в отношение проверки конфликтов сетевого уровня и их устранения.

Я не очень понял, что вы имели ввиду, когда говорили об ошибке, в том случае, если узел получает два ответа на ARP request. Где вы наблюдаете такое поведение? И самое главное, к чему ведёт такая ситуация на узле получателе?

С точки зрения узла, получившего два ответа, нет не какой проблемы, он заменит первый пришедший ответ, вторым.

С точки зрения узлов, которые дали такой ответ, проблемы тоже нет, поскольку они используют одноадресный ARP reply, иными словами оба узла буду считать, что второго узла не существует в сети с таким же адресом.

Если мы заглянем в ARP пакет, направляемый при выполнение процедуры IP DAD, воспользовавшись tcpdump, то увидим, что ARP request выглядит следующим образом:

nbytes: (ar$sha) Source MAC нашего узла mbytes: (ar$spa) 0.0.0.0 nbytes: (ar$tha) FF:FF:FF:FF:FF:FF (00:00:00:00:00:00) mbytes: (ar$tpa) IP адрес нашего узла

ar$tpa содержит нас собственный адрес, а ar$spa заполнен 0.0.0.0, что совершенно не характерно для классического ARP request, поэтому такой пакет называется ARP Probe.

Ответом на такой ARP Probe, будет ARP reply, на наш MAC адрес, указанный в поле ar$sha, что автоматически позволит нашему узлу узнать, что такой адрес уже занят.

Стандарт так же предписывает, выполнять следующую проверку, когда наш узел получает ARP request/reply, если ar$sha != MAC любого из наших интерфейсов, а ar$spa = IP любого из наших интерфейсов, то в сети существует конфликт IP адресов.

Но, получить ARP reply мы можем только в одном случае, если он был направлен не одноадресным кадром, а широковещательным. Лично я не встречал таких реализаций, а значит проверка сужается только до ARP request пакетов.

Исходя из выше изложенного я считаю, что ваше утверждение о том, что это особенность функционирования Ethernet сетей, ошибочна. Хотя в случае inverse ARP, ar$sha содержит Frame Relay DLCI или ATM VCI/VPI, который к тому же, ещё и меняется на каждом коммутаторе, тем не менее, это не ломает логику проверки, а только слегка меняет её.

Если мы получили кадр который содержит ar$sha = DLCI/VCI/VPI нашего PVC, а это всегда будет правдой, наш интерфейс заменяет ar$sha кадра при получение на собственный и ar$spa = IP нашего любого интерфейса, то в сети существует конфликт IP адресов.