요약

  • RFC 919는 "모든 호스트"를 뜻하는 목적지로 호스트 필드가 전부 1인 값을 선택했고, 255.255.255.255를 접속된 네트워크에서 전달되지 않는 브로드캐스트로 정했습니다.
  • RFC 922는 IP 데이터그램 형식을 바꾸지 않으면서 같은 관례를 서브넷 범위로 확장했습니다.
  • RFC 1122는 전부 1인 형식들을 표준화하고 수신자가 이전의 전부 0인 변형도 인식하도록 권고하여, 비대칭적인 마이그레이션 규칙을 만들었습니다.

하나의 목적지가 더 이상 한 호스트의 이름이 아니게 된 순간

IPv4 기본 사양은 인터넷 데이터그램을 브로드캐스트하는 데 동의된 방법을 정의하지 않았습니다. RFC 919는 로컬 네트워크의 모든 스테이션에 도달하는 효율적인 방법을 이미 제공하던 링크 계층에서 출발하여, 수신 대기 중인 모든 호스트가 패킷을 받아들여야 할 때 IP 패킷이 어떤 목적지를 담아야 하는지 물었습니다.

이것은 단순한 전송 메커니즘의 문제가 아니었습니다. 호스트는 보통 목적지가 자신의 IP 주소 중 하나와 일치할 때 데이터그램을 받아들입니다. 브로드캐스트를 지원한다는 것은, 어떤 단일 호스트도 소유하지 않은 목적지를 관련 네트워크의 모든 수신자가 자신의 것으로 인식하도록 또 다른 목적지 계층을 추가한다는 의미였습니다.

RFC 919는 이 서비스를 의도적으로 약하게 유지했습니다. 브로드캐스트 데이터그램은 신뢰할 수 없고, 순서가 보장되지 않으며 중복될 수도 있었습니다. 수신 대기 중인 모든 호스트가 최소한의 처리 비용을 부담하므로, 브로드캐스트는 신뢰성 있는 그룹 전달 기본 요소로 쓰이는 것이 아니라 최선의 해법일 때만 사용해야 했습니다.

모두를 위한 숫자 선택

상호 운용성을 위해서는 "모든 호스트"를 뜻하는 특별한 호스트 번호가 필요했습니다. 이 선택은 기술적으로 임의적이었는데, 로컬 네트워크가 IP 목적지를 자신의 브로드캐스트 주소로 사상할 수 있었기 때문입니다. RFC 919는 비트가 모두 1인 값을 선택했습니다. 이 값은 실제 호스트에 할당되었을 가능성이 낮았고, 드문 충돌 할당은 번호를 다시 매기면 되었습니다.

이 규칙은 즉시 서로 다른 두 가지 범위를 만들어냈습니다. 목적지 255.255.255.255는 접속된 물리 네트워크의 모든 호스트를 의미했고 전달되어서는 안 되었습니다. 자신의 네트워크 번호를 아직 모르는 호스트도 이를 사용해 로컬 서비스에 도움을 요청할 수 있었습니다. 반면 36.255.255.255 같은 주소는 네트워크 36의 모든 호스트를 의미했습니다. 라우터는 마지막 게이트웨이가 링크 계층 브로드캐스트로 확장하기 전까지 데이터그램을 해당 네트워크 쪽으로 운반할 수 있었습니다.

따라서 같은 비트 패턴이 항상 같은 지리적 도달 범위를 의미하지는 않았습니다. 주소 계층 구조 안에서 그 위치가 중요했습니다. 주소 전체가 1이면 범위가 제한된 로컬 브로드캐스트였고, 호스트 부분만 1이면 선택된 네트워크로 향하는 지정 브로드캐스트였습니다.

RFC 919는 0으로 된 필드에 표기법상 미지정 또는 네트워크 전체라는 대조적 의미를 부여했습니다. 예시에서 36.0.0.0은 네트워크 36을, 36.255.255.255는 네트워크 36의 모든 호스트를 나타냈습니다. 이 깔끔한 대조가 0을 브로드캐스트로 사용하던 배포된 시스템을 지워버리지는 못했지만, 표준이 나아갈 방향을 정했습니다.

서브넷을 통한 의미 확장

서브네팅은 주소의 로컬 부분을 서브넷 번호와 호스트 번호로 나눕니다. RFC 922는 IP 데이터그램 형식을 바꾸지 않고도 브로드캐스팅이 이 새로운 계층 구조를 따를 수 있음을 보였습니다. 기존의 주소 비트는 어느 필드가 특별한 값으로 설정되었는지에 따라 한 하드웨어 네트워크의 모든 호스트, 한 서브넷의 모든 호스트, 또는 한 네트워크의 모든 서브넷을 지명할 수 있었습니다.

이 유연성은 복잡성을 해석과 포워딩 쪽으로 옮겼습니다. 수신자는 네트워크·서브넷·호스트 필드의 경계를 알기 위해 활성 주소 마스크가 필요했습니다. 게이트웨이는 정상적으로 전달할지, 접속된 네트워크에 링크 계층 브로드캐스트를 내보낼지, 아니면 멈출지를 결정해야 했습니다.

루프 방지도 이 계약의 일부였습니다. RFC 922의 기본 규칙은 데이터그램이 도착한 하드웨어 네트워크에서는 절대 브로드캐스트하지 않는 것이었습니다. 게이트웨이가 자기 자신이 내보낸 패킷을 듣는 것만 회피해서는, 여러 게이트웨이가 서로의 패킷을 듣고 반복할 수 있는 상황에서 충분하지 않았습니다.

위험은 ARP와의 경계에서도 나타났습니다. RFC 919는 ARP 서버가 목적지가 IP 브로드캐스트 주소인 요청에는 응답해서는 안 된다고 경고했습니다. 그런 요청은 특별한 목적지를 인식하지 못한 호스트가 보낸 것이었습니다. 유니캐스트처럼 보이는 사상을 제공하면 포워딩 루프에 연료를 공급할 수 있었고, 혼란에 빠진 여러 호스트가 재브로드캐스트를 극적으로 증폭시킬 수 있었습니다.

따라서 이 주소 관례는 인식과 분리할 수 없었습니다. 브로드캐스트 값은 호스트, ARP 동작, 게이트웨이가 모두 그것이 일반적인 호스트 주소가 아니라고 합의할 때만 작동했습니다.

표준적인 송신자, 관대한 수신자

RFC 1122는 네 가지 표준 전부-1 형식을 정리했습니다. 제한 브로드캐스트를{-1,-1}, 지정 브로드캐스트를{network,-1}, 서브넷 지정 브로드캐스트를{network,subnet,-1}, 전체 서브넷 지정 브로드캐스트를{network,-1,-1}로 기술했습니다. 이 표기법에서 -1은 해당 필드의 모든 비트가 1임을 뜻합니다.

호스트는 이 표준 형식들을 수신 목적지로 인식하도록 요구받았습니다. 그러나 사양은 4.2BSD 후손들을 포함해 -1 대신 0을 대입하는 구현 계열도 인정했습니다. 호스트는 그런 비표준 0 형식도 인식해야 했습니다. 인터페이스는 어느 형식을 보낼지 선택할 수도 있었지만 기본값은 표준 전부-1 형식이어야 했습니다.

이것은 비대칭적인 마이그레이션 전략이었습니다. 수신은 관대함을 유지함으로써 배포된 불일치를 넘어 통신할 수 있게 했습니다. 송신은 하나의 관례로 수렴함으로써 불일치가 무한히 재생되지 않도록 했습니다. 낡은 바이트들은 동등하게 표준으로 선언되지 않았고, 호환성 입력으로 보존되었습니다.

RFC 1122는 또한 IP와 링크 계층의 의미를 연결했습니다. 호스트가 링크 계층 브로드캐스트 주소로 보낼 때 IP 목적지는 합법적인 브로드캐스트 또는 멀티캐스트 주소여야 했습니다. 반대로 호스트는 링크 브로드캐스트로 수신한 프레임의 IP 목적지가 브로드캐스트도 멀티캐스트도 아니라면 폐기해야 했습니다. 하드웨어 전달만으로 모든 IP 스택이 일반 유니캐스트 패킷을 처리할 권위는 없었습니다.

제한된 범위가 견고성을 높인 이유

RFC 1122는 접속된 네트워크에 대해 제한 브로드캐스트 주소를 권고했습니다. 서브넷 지정 주소는 서브네팅을 이해하지 못하거나 주소를 다르게 나누는 기계들을 혼란스럽게 할 수 있었습니다. 그런 호스트들은 송신자가 "여기 모두"를 의도한 것을 어떤 다른 개별 호스트의 주소로 볼 수도 있었습니다.

전부-1 관례는 그런 차이를 없앤 것이 아니라 차이를 표현하기 위한 일관된 어휘를 제공한 것입니다. 제한 형식은 접속된 네트워크의 번호와 마스크에 대한 지식에 의존하지 않았고, 전달 금지 규칙이 전파에 단단한 경계를 놓았습니다.

지정 브로드캐스트는 여전히 별개의 동작이었습니다. RFC 919는 게이트웨이가 성능이나 보안상의 이유로 포워딩을 거부할 수 있도록 허용했습니다. 목적지는 의도된 범위를 기술했지만, 패킷이 확장을 담당하는 게이트웨이에 도달할지는 정책과 토폴로지가 계속 통제했습니다.

이 주소 계약이 확립한 것

IPv4 브로드캐스트 주소 지정은 헤더 필드를 추가하지 않고 기존의 링크 기능을 네트워크 계층 관례로 전환했습니다. 주소 값을 예약하고, 주소 구조를 통해 그 범위를 정의하고, 게이트웨이 동작을 제약하고, 수신자 호환성을 배포의 일부로 만들었습니다.

이 역사는 단순히 1이 0을 이겼다는 이야기가 아닙니다. 전부 1은 순응하는 송신자의 안정적인 출력이 되었고, 0 형식의 수용은 수신자의 과도기적 의무로 남았습니다. 그 조합 덕분에 구현들은 즉각적인 플래그 데이를 요구받지 않으면서 수렴할 수 있었습니다.

또한 "모든 호스트"가 신뢰할 수 있는 전달을 의미하지도 않았습니다. 브로드캐스트는 유실되거나 중복될 수 있었고, 게이트웨이는 지정 형식을 제한할 수 있었으며, 각 수신자는 여전히 패킷을 어떻게 처리할지 판단하는 자원을 소모해야 했습니다. 지속된 성과는 더 좁았습니다. 호스트와 라우터가 어떤 목적지가 단일 기계가 아니라 범위를 지명하는 것임을 공유된 방식으로 인식할 수 있게 된 것입니다.

출처