IPv6 이웃 요청이 유니캐스트 주소 대신 멀티캐스트를 사용하는 이유는 무엇입니까?

IPv6 이웃 요청이 유니캐스트 주소 대신 멀티캐스트를 사용하는 이유는 무엇입니까?

fe80::1234:56ff:fe12:3456%eth0저는 Linux를 사용하고 있으며 인터페이스 와 동일한 이더넷 스위치에 연결된 ping을 실행하고 싶습니다 eth0. 아직 와 통신한 적이 없어서 fe80::1234:56ff:fe12:3456MAC 주소가 캐시되어 있지 않습니다(에 없습니다 ip neigh list). 내가 달릴 때

ping fe80::1234:56ff:fe12:3456%eth0

나는 보낸다

  • 내부의 ICMP 이웃 요청 패킷
  • ff02::1:ff12:3456내부에 멀티캐스트 대상 주소가 있는 IPv6 데이터그램
  • 멀티캐스트 대상 주소가 있는 이더넷 프레임 33:33:ff:12:34:56.

이는 ff02::1:ff12:3456MAC 주소의 하위 24비트로 구성되어 있으며 동일한 비트를 공유하는 노드는 모두 이 멀티캐스트 주소를 수신합니다. 그런데 왜 이렇게 지정되어 있는 걸까요? ICMP 패킷을 대상 IPv6 주소로 직접 보내 멀티캐스트 MAC 주소가 가능한 후보에게 배포하도록 하면 어떨까요? 이와 같이:

  • 내부의 ICMP 이웃 요청 패킷
  • fe80::1234:56ff:fe12:3456내부에 유니캐스트 대상 주소가 있는 IPv6 데이터그램
  • 멀티캐스트 대상 주소가 있는 이더넷 프레임 33:33:ff:12:34:56.

답변1

이더넷은 어디에나 있지만 유일한 레이어 2 기술은 아닙니다.

"IPv6 패킷 오버"를 스크롤합니다.RFC다음을 포함한 다양한 링크 레이어를 공개합니다.블루투스 저에너지 ITU-T G.9959 개인 영역 네트워크,파이버 채널. 또한 토큰 링이나 FDDI와 같은 쓸모없는 대안도 있습니다.

멀티캐스트 맵 IPv6 멀티캐스트 주소를 구현하는 링크 계층입니다. 그 문제를 해결하지 못하는 사람들. 아마도 지점 간 링크를 통해 라우터가 멀티캐스트 수신기를 추적할 수 있습니다. 또는 ARP와 같이 모든 노드에 전송하는 것이 이상적이지는 않지만 브로드캐스트 구현일 수도 있습니다.

이웃 발견IP 스택에서는 일관된 추상화 및 코드 재사용이라는 이점이 있습니다. 링크 계층 주소를 얻기 위해 대상 IP 패킷을 생성할 수 있습니다. 레이어 3 코드가 작성될 당시에는 상상할 수 없었던 하드웨어를 포함합니다.

또한보십시오: MAC 주소를 얻으려면 IPv6 Neighbor Solicitation이 필요한 이유는 무엇입니까?

답변2

답변자가 귀하의 질문을 이해하지 못한 것 같습니다 :-). 나는 또한 이 질문을 가지고 있으며 Stefan van den Akker(여기서 질문의 저자 -https://networkengineering.stackexchange.com/questions/63841/why-not-put-unicast-address-in-ipv6-packet-포함-ndp-neighbor-solicitation) 이렇게 하면 원치 않는 라우팅 문제를 해결할 수 있다고 말했습니다.

(이 접근 방식에서 생각할 수 있는 한 가지 문제는 동일한 링크에 있지 않은 장치의 글로벌 유니캐스트 주소를 요청할 때 라우터가 내 패킷을 링크 외부로 라우팅할 수 있다는 것입니다. 이는 원치 않는 동작입니다.)

또한 균일성을 위해(ipv6 멀티캐스트는 이더넷 멀티캐스트로 변환되며 이웃 요청에 대한 이 규칙에 대한 예외는 균일성을 깨뜨릴 수 있습니다).

위에서 언급한 것 외에는 다른 아이디어가 없습니다. 물론 OS 커널의 네트워크 계층은 원하는 모든 필요한 패킷을 구성할 수 있기 때문입니다. 또한 멀티캐스트 mac 주소와 유니캐스트 ipv6 주소가 포함된 패킷도 있습니다.

관련 정보