요약

  • RFC 826은 좁지만 결정적인 문제를 해결했다. IP 라우팅이 다음 프로토콜 주소를 선택한 뒤에도 이더넷 인터페이스에는 하드웨어 목적지가 필요했다. 호스트는 표에 답이 없을 때만 로컬 케이블에 질문을 던졌다.
  • 이 요청은 답을 청하는 데 그치지 않았다. 모든 청취자는 발신자의 주장을 관찰할 수 있었고, 대상은 답하기 전에 요청자를 학습했다. 캐시는 그 관찰을 실행 가능하게 만들었고, 이후의 규칙들은 그것을 만료시켰다.
  • 프록시 응답과 주소 충돌 검출은 ARP의 권한 경계를 드러냈다. 응답은 신원이 아니라 전달 약속일 수 있으며, DHCP 임대나 수동 설정조차 로컬 링크의 증거에 의해 거부될 수 있다.

라우팅 이후에 남는 빈 목적지

IP 스택은 다음 패킷이 접속된 네트워크의 호스트 또는 더 먼 곳으로 전달할 라우터로 향한다고 판단할 수 있다. 그러나 그 결정만으로는 이더넷 인터페이스가 프레임에 넣을 목적지를 알 수 없다. 인터넷 주소와 48비트 하드웨어 주소는 서로 다른 종류의 이름이며, 어느 쪽도 다른 쪽에서 신뢰할 수 있게 유도할 수 없다.

RFC 826은 1982년 11월 David C. Plummer가 발표한 문서로, 정확히 이 경계에서 출발했다. 그 예시 프로토콜은 이미 연결된 10메가비트 이더넷에서 대상을 선택한 상태였고, 남은 일은 '프로토콜 유형과 대상 프로토콜 주소'의 쌍을 로컬 네트워크가 사용할 수 있는 하드웨어 주소로 변환하는 것이었다.

패킷 형식은 이 불일치를 명시적으로 드러냈다. 하드웨어 유형, 프로토콜 유형, 각 주소의 길이, 연산 코드, 그리고 발신자와 대상의 주소가 두 이름 공간 모두에서 담겼다. IPv4 over Ethernet이 익숙한 사용례가 되었지만, 이 형식은 모든 프로토콜 주소가 32비트이고 모든 로컬 매체가 이더넷이라고 가정하지 않았다. 해석은 이름 공간들 사이의 관계였지, 하나의 주소 안에 숨겨진 속성이 아니었다.

이것이 중요한 이유는 이 매핑이 라우팅이 아니기 때문이다. 라우팅은 다음 프로토콜 목적지와 출력 인터페이스를 선택한다. ARP는 그 선택 이후, 선택된 로컬 링크 안에서만 작동한다. IP 목적지가 원격이라면 하드웨어 주소는 보통 먼 서버가 아니라 다음 홉 라우터의 것이다. 따라서 프레임과 패킷은 모순 없이 서로 다른 목적지를 가리킬 수 있다.

1982년 제안은 완전한 중앙 표를 피했다. 로컬 주소 해석 모듈은 먼저 자신의 변환 캐시를 살펴보고, 매핑이 존재하면 하드웨어 주소를 돌려주어 전송을 계속할 수 있게 했다. 없으면 요청을 만들어 라우팅이 선택한 이더넷에 브로드캐스트했다. 질문의 범위는 제한되어 있었고, 필요할 때 생성되었다.

가까운 모두에게 보낸 질문

브로드캐스트는 미지의 주소를 공유된 로컬 사건으로 만들었다. 요청자는 자신의 하드웨어·프로토콜 주소를 제공하고, 원하는 프로토콜 주소를 지명하며, 대상 하드웨어 주소는 비워 두었다. 그 케이블의 모든 스테이션이 프레임을 받을 수 있었지만, 관련 하드웨어·프로토콜 공간을 이해하고 자신이 대상임을 인식한 스테이션만 응답하면 되었다.

응답은 요청자에게 유니캐스트로 돌아갔다. 이 비대칭성은 발견 과정은 보이게 하면서 답이 또 하나의 필수 브로드캐스트가 되는 것을 막았다. 또한 모든 매핑의 주기적 광고를 피했다. RFC 826은 요청 시 해석을, 쓰지도 않을 항목으로 가득한 표를 반복해서 브로드캐스트하는 워크스테이션과 명시적으로 비교했다. 필요할 때 묻고, 중요한 것은 기억하며, 모든 동료가 같은 세계 관을 유지하도록 강요하지 않는 것이다.

이 절약에는 대가가 있었다. 해석이 진행되는 동안 첫 패킷은 상위 계층이 재시도할 것이라는 가정 아래 폐기될 수 있었다. 호스트 요구사항 문서는 나중에 이 동작을 다듬었다.RFC 1122는 링크 계층이 미해결 목적지에 대해 최소한 최신 패킷 하나는 저장해야 한다고 규정했다. 한 패킷을 큐에 넣는 것은 모든 교환의 첫 패킷 손실을 피하지만, 여전히 로컬 실행 상태일 뿐이다. 그것은 주소의 소유자가 누구인지에 대해 아무것도 말하지 않는다.

브로드캐스트에는 절제도 필요하다. RFC 1122는 같은 목적지에 대한 반복 요청이 ARP 플러드로 번지지 않도록 하는 메커니즘을 요구하고, 목적지당 초당 최대 한 번의 요청을 권고했다. 답 없는 질문은 무한히 증폭될 수 없다. 침묵은 부재, 손실, 잠자는 호스트, 세분화 또는 적대적 방해를 뜻할 수 있다. 반복은 부하를 바꿀 뿐, 확실성을 바꾸지 않는다.

연산 코드를 확인하기 전에 학습하기

RFC 826에서 가장 계몽적인 부분은 수신 알고리즘의 순서다. 스테이션은 먼저 해당 하드웨어·프로토콜 유형을 이해하는지 확인한다. 발신자의 프로토콜 주소에 대한 항목이 이미 있으면, 패킷에서 관찰된 하드웨어 주소로 그 항목을 갱신한다. 자신이 지명된 대상인데 발신자 항목이 없으면 하나를 추가한다. 그 후에야 이 패킷이 응답이 필요한 요청인지 검사한다.

따라서 요청은 질문인 동시에 증거였다. A는 사실상 "누가 B로 향하는 트래픽을 받을 수 있는가?"라고 묻는 동시에 "A로 향하는 응답은 이 하드웨어 주소에 도달할 수 있다"고 진술한다. B는 답하기 전에 답하는 방법을 배운다. 수동 모니터도 케이블 위의 상위 계층 프로토콜을 말하지 않고 발신자 매핑을 수집할 수 있다.

RFC 826은 새 발신자 하드웨어 주소가 이전 것을 대체하는 것을 허용했다. 매핑이 바뀐 네트워크의 회복에 도움이 되지만, 프로토콜의 신뢰 모델도 드러낸다. 최근에 관찰된 주장이 캐시에 영향을 미친다는 것이다. 패킷은 신원에 대한 암호학적 증명을 담지 않는다. 수신자는 그 매핑을 소유권 증서가 아니라 유용한 로컬 정보로 다뤄야 했다.

원래 메모는 표의 노화와 타임아웃을 논의했지만 프로토콜 밖으로 남겨 두었다. 잘못된 데이터나 이동한 호스트가 다른 기계들을 낡은 주소로 향하게 남길 위험을 인식하고 있었다. 7년 뒤 RFC 1122는 이 우려를 요구사항으로 만들었다. ARP 구현은 오래된 항목을 플러시하는 메커니즘을 갖추어야 하며, 시간이 선택된 메커니즘이라면 타임아웃 값은 설정 가능해야 한다.

RFC 1122가 기술한 것은 시계 이상이었다. 호스트는 캐시된 하드웨어 주소를 직접 폴링하거나, 링크 계층의 조언을 받아들이거나, 상위 계층이 보고한 실패를 사용할 수 있다. 이 메커니즘들은 무엇이 반증 증거인지에 대해 의견이 갈리지만, 모두 영속성을 거부한다. 캐시는 일시적 불완전성을 수용함으로써 반복 실행을 가속한다. 그 안전은 출구에서 나온다.

누군가를 대신해 게이트웨이가 답했을 때

ARP의 응답은 흔히 대상 자신이 하드웨어 신원을 선언하는 것처럼 묘사된다. 1987년 10월 발표된RFC 1027은 그 해석이 너무 강하다는 이유를 문서화했다. 텍사스 대학의 네트워크는 서브넷이 필요했지만, 다수의 호스트 운영체제는 서브네팅을 구현하지 않았다. Proxy ARP는 게이트웨이가 새 경계를 숨기게 했다.

A가 B를 위해 브로드캐스트한다고 하자. 게이트웨이는 질문을 듣고, 자신의 라우팅 표에서 B가 다른 물리 네트워크 너머에 있음을 안다. 그것은 자신의 하드웨어 주소로 응답한다. A는 그 매핑을 캐시하고, 게이트웨이로 향하는 프레임 안에 B의 IP 주소로 향한 패킷을 담아 보낸다. B 쪽에서는 다른 프록시 응답이 돌아가는 경로를 마련할 수 있다.

엔드포인트는 서브넷을 보지 못한다. 호환성이 이득이다. 한여섯 개가 넘는 운영체제를 한꺼번에 바꾸지 않아도 되었다. 그러나 이제 응답은 명백히 위임된 것이다. 응답한 하드웨어는 최종 IP 엔드포인트라고 주장하는 것이 아니라, 로컬 프레임을 받아 그 안의 패킷을 전달하겠다고 약속하는 것이다.

그 약속은 ARP 바깥의 라우팅 지식과 행정적 일관성에 의존한다. 여러 게이트웨이가 응답하면 첫 응답이 캐시를 좌우할 수 있다. 게이트웨이가 올바르게 도달할 수 없는 목적지를 프록시하면, 로컬 매핑은 완전해 보이지만 전달은 나중에 실패한다. Proxy ARP는 오래된 호스트를 지키고 토폴로지를 숨기는 대신, 로컬 해석과 라우터 정책 사이의 보이지 않는 결합이라는 대가를 치른다.

이 예는 유용한 경계를 세운다. 응답을 관찰했다는 것은 누군가 사용 가능한 후보로 응답했다는 것을 증명한다. 그것은 물리적 공존, 엔드포인트 신원, 해당 IP 주소를 소유할 권한, 응답자 너머의 성공적 전달을 증명하지 않는다.

와이어가 여전히 거부할 수 있는 임대

중앙 구성이 로컬 검증을 없애지는 않았다. 1997년 동적 호스트 구성 프로토콜 사양인RFC 2131은 서버가 주소를 제안하고 임대할 수 있게 한다. 그러나 재할당 전에 서버가 주소를 검사하도록 권하고, 클라이언트에게 DHCPACK 수신 후 최종 확인을 수행하도록 지시한다.

클라이언트는 자신의 하드웨어 주소, 대상으로서의 제안된 주소, 그리고 전부 0인 발신자 IP로 ARP 요청을 보낼 수 있다. 0이 중요하다. 호스트는 이미 주소를 사용하고 있다고 주장하기 전에, 그 주소를 사용할 수 있는지 먼저 묻는 것이다. 다른 수신자는 클라이언트가 버려야 할지도 모르는 매핑으로 자신들의 캐시를 채우지 않아야 한다.

클라이언트가 주소가 사용 중임을 발견하면 DHCPDECLINE을 보내고 구성을 다시 시작해야 한다. 검사가 성공하면, 이전 사용자가 남긴 낡은 항목을 동료들이 버릴 수 있도록 매핑을 알려야 한다. 서버의 임대는 유효한 행정 기록이지만, 로컬 링크는 여전히 즉각적 사용을 위험하게 만드는 증거를 제공할 수 있다.

이것은 DHCP와 ARP의 대결이 아니다. 둘은 서로 다른 질문에 답한다. 서버는 주소 풀과 임대를 조율한다. ARP는 그 결정이 놓이게 될 실행 환경을 관찰한다. 할당 기록은 내부적으로 올바를 수 있지만, 와이어에는 낡은, 중복된, 악의적인 청구자가 있을 수 있다.

한 번의 조회에서 지속적 충돌 검출로

RFC 3927은 2005년 IPv4 링크 로컬 주소를 위해 로컬 검증에 시간이 매겨진 절차를 부여했다. 호스트는 무작위 간격을 기다리고, 발신자 IP가 0인 탐지를 브로드캐스트하며, 응답이든 경쟁 탐지든 후보가 사용 중이라는 증거로 다룬다. 성공 후에는 발신자·대상 IP 필드가 모두 선택된 주소를 담은 공지를 브로드캐스트한다.

많은 호스트가 함께 시작할 때 무작위 타이밍이 중요하다. 충돌 카운터와 속도 제한은 고장 나거나 적대적인 장치가 모든 탐지에 응답할 때 중요하다. 프로토콜은 불확실성을 무한 브로드캐스트 폭풍으로 바꿔서는 안 된다. 공지가 중요한 이유는 다른 호스트가 여전히 이전 하드웨어 매핑을 캐시하고 있을 수 있기 때문이다.

절차는 구성 이후에도 계속된다. 서로 연결되지 않은 두 이더넷 세그먼트가 각각 같은 링크 로컬 주소를 쓰는 호스트를 담고 있을 수 있다. 세그먼트가 나중에 연결되면, 과거의 부팅 시 검사는 그 충돌을 막을 수 없다. 따라서 RFC 3927은 호스트가 사용 기간 내내 충돌을 감시할 것을 요구한다.

2008년 발표된RFC 5227은 IPv4 주소 충돌 검출을 일반화했다. 이 문서는 ARP Probe를 질문("누군가 이 주소를 사용하고 있는가?")이자 함축된 진술("이것이 내가 사용하기 희망하는 주소이다")으로 기술한다. 공지는 발신자가 지금 그 주소를 사용하고 있다는 더 강한 진술을 한다.

충돌 이후 호스트는 즉시 철수하거나 한 번 공지하여 주소를 방어할 수 있다.DEFEND_INTERVAL안에 또 다른 충돌이 오면, 일반 호스트는 끝없는 경쟁에 들어가는 대신 주소 사용을 중단하고 실패를 보고해야 한다. 의도적으로 구성된 라우터나 DNS 서버 같은 일부 인프라는 안정적 주소를 절대 내놓지 않도록 설정될 수 있지만, 그 예외조차 통제된 공지와 운영자의 가시성을 요구한다.

충돌 검출은 소유권을 인증하지 않으면서 안전을 개선한다. 공격자는 정당한 호스트가 자신의 주소가 충돌한다고 믿게 하여 서비스 거부를 일으킬 수 있다. 조용한 탐지는 잠자거나 분리된 청구자를 놓칠 수 있다. 이 프로토콜은 경계가 정해진 운영 검사를 확립한다. 행동을 바꾸기에 충분하지만, 법적 또는 전 세계적 신원을 확정하기에는 결코 충분하지 않다.

ARP 번호 레지스트리가 관할하지 않은 것

ARP 자체에는 번호 공간이 있다. 구현은 하드웨어 유형과 연산 코드에 대해 합의해야 같은 비트가 같은 방식으로 해석된다. 2009년 발표된RFC 5494는 이 값들을 할당하기 위한 IANA 지침을 제공하고 실험용 범위를 예약했다.

이것은 실제 조율이지만, 그 범위는 과장하기 쉽다. IANA는 특정 이더넷에서 어느 기계가 192.0.2.7을 사용할 수 있는지 결정하지 않고도, "이 필드는 특정 하드웨어 유형을 사용한다"는 코드 포인트 의미를 유지할 수 있다. 프로토콜 어휘의 레지스트리는 그 어휘로 표현되는 모든 청구의 레지스트리가 아니다.

이 구분은 ARP가 드러낸 아키텍처를 그대로 비춘다. 공유된 사양은 메시지를 상호운용 가능하게 한다. 로컬 관찰은 후보를 제공한다. 캐시는 한 후보를 행동으로 바꾼다. 타이머, 새 패킷, 라우팅 정책 또는 충돌 검출이 그 행동을 수정할 수 있다. 각 계층에는 다른 권한이 작동하며, 한 계층의 증거를 다른 계층의 명령으로 착각할 때 실패가 따른다.

잊어야 하는 로컬 장부

ARP는 완전한 진실 체계보다 덜 요구했기에 성공했다. 모든 호스트가 미리 하나의 서비스에 등록할 것을 요구하지 않았다. 모든 매핑의 브로드캐스트도 요구하지 않았다. 한 호스트가 가까운 질문을 던지기에 충분한 공통 문법과, 모든 패킷마다 물어보지 않기에 충분한 로컬 기억을 요구했다.

그 겸손이 곧 취약성이다. 공통 와이어는 호스트가 신뢰하지 않을 수도 있는 당사자들에게 관찰 가능하다. 가장 새로운 주장은 거짓일 수 있다. 프록시는 의존성을 숨길 수 있다. 캐시는 그것을 만든 토폴로지보다 오래 살아남을 수 있다. 이 설계는 운영자가 표를 작업 가설로 다룰 때만 계속 사용 가능하다. 범위가 정해져 있고, 시간에 따라 노화되며, 라우팅·스위칭 증거와 비교되고, 현실이 바뀌면 교체 가능해야 한다.

ARP는 케이블을 권위로 만들지 않았다. 케이블을 증인으로 만들었다. 호스트는 여전히 캐시할지, 보낼지, 다시 탐지할지, 방어할지, 철수할지를 결정하며, 로컬 진술을 영구적 신원으로 착각한 결과를 감당한다.

출처와 증거의 한계

RFC 826은 원래의 패킷 형식, 요청 시 브로드캐스트, 연산 코드 이전 병합 알고리즘, 캐시 대체, 그리고 미해결로 남은 노화 논의를 제공한다. RFC 1027은 Proxy ARP를 호환성 메커니즘으로 문서화하며 응답이 위임될 수 있음을 보여준다. RFC 1122는 캐시 무효화와 요청 조절을 호스트 요구사항으로 만든다.

RFC 2131은 DHCP 할당을 클라이언트의 로컬 중복 검사와 분리한다. RFC 3927은 링크 로컬 탐지, 공지, 지속적 관찰, 폭풍 제한을 규정한다. RFC 5227은 IPv4 충돌 검출과 경계가 정해진 방어를 일반화한다. RFC 5494는 ARP 코드 포인트 할당을 관할한다.

이 문서들은 설계와 요구사항을 확립하는 것이지, 인터넷 전역의 채택 통계가 아니다. ARP 캡처는 어느 한 링크에서 어느 한 시점에 관찰된 것을 확립한다. 그것만으로는 인증된 신원, 전 세계적 소유권, 의도, 또는 프록시 응답 이후의 성공적 전달을 확립하지 않는다.