요약

  • STD 48로 발표된 RFC 1088은 IP 데이터그램을 NetBIOS 데이터그램 안에 담아 전송하며, 수신 NetBIOS 이름을 IP 주소에서 기계적으로 도출했습니다:IP.XX.XX.XX.XX.
  • 이 메커니즘은 해당 매핑을 위한 물리 주소 질의를 피한 것입니다. 경로를 찾은 것도, 어느 엔드포인트를 누가 통제하는지 증명한 것도, IP 멀티캐스트를 지원한 것도, IP 데이터그램이 애플리케이션에 도달했음을 입증한 것도 아닙니다.

이 공식을 거꾸로 읽고 싶은 유혹이 있습니다. 눈에 보이는 고정된 이름이 기계에 대한 주장처럼 보이기 때문입니다. 그러나 그렇지 않습니다.RFC 1088은 NetBIOS 네트워크에서 IP 데이터그램을 전송하기 위한 호환 방법을 규정합니다. 이 문서가 규제하는 행위는 캡슐화입니다. IP 데이터그램이 NetBIOS 데이터그램의 데이터가 되고, 수신자는 목적지 IP 주소에서 도출한 NetBIOS 이름으로 선택됩니다.

두 로컬 관례를 접목하기 위한 합리적 방법이었습니다. NetBIOS 이름은 16바이트까지 가능했습니다. RFC 1088은 IP 애플리케이션을 위해 알아볼 수 있는 형태를 예약했습니다. 즉IP.접두어 뒤에 네 개의 주소 바이트를 ASCII 16진수로 이어 붙입니다. 도출은 결정적입니다. 주소와 이 관례만 있으면 송신자가 물리 주소를 알아내기 위해 질문을 브로드캐스트할 필요가 없습니다. RFC는 그 사실을 ARP 같은 물리 주소 질의 메커니즘과 명시적으로 대조합니다.

그 절감은 좁아서야 가치가 있습니다. 질의 하나가 피해졌을 뿐, 표 조회가 증명으로 변하지는 않았습니다. 결과로 나온 이름은 누가 IP 주소를 소유하는지, 호스트가 살아 있는지, 네트워크가 데이터그램을 받아들이는지, 라우터가 존재하는지, 상위 계층이 내용을 수용하는지 말해 주지 않습니다.RFC 791은 이 지속적인 구분을 그립니다. 이름, 주소, 경로는 서로 다른 직무입니다. RFC 1088은 IP 주소와 NetBIOS 전달 이름 사이의 한 가지 로컬 매핑을 수행합니다. 철자를 들여다보기 쉽다는 이유만으로 다음 직무까지 수행하지 않습니다.

두 개의 등록, 그리고 계속되는 수신

구현 절은 이 경계를 수사가 아니라 운용적으로 만듭니다. 각 IP 주소에 대해 호스트는 도출된IP.XX.XX.XX.XX이름을 NetBIOS 이름 표에 추가합니다. 또한 그룹 이름IP.FF.FF.FF.FF를 추가합니다. 그리고 양쪽 이름에 대해 수신 데이터그램 요청을 게시합니다. 어느 이름으로 데이터그램이 도착하면 프로토콜 스택이 이를 처리하고 다시 수신 요청을 게시합니다. 종료 시에는 대기 중인 수신을 취소하고 두 이름을 삭제합니다.

이것은 로컬 상태입니다. 숨은 토폴로지를 학습하는 발견 시스템이 아닙니다.RFC 950에서 다룬 투명 서브넷 기제와 유사하지 않습니다. 그곳에서는 브리지가 호스트의 위치를 발견해야 할 수 있고 캐시가 그 정보와 함께 커집니다. NetBIOS 표를 전역 디렉터리로 만들지도 않습니다. 이 지정된 운반체에서 특정 호스트가 어떤 이름을 받아들여야 하는지만을 말합니다.

이 구분은 ARP와의 관계도 명확히 합니다.RFC 826은 자신의 맥락에서 프로토콜 주소를 이더넷 주소로 매핑하는 해결 메커니즘을 규정합니다. RFC 1088은 ARP를 일반적인 도달 가능성 이론으로 대체하지 않습니다. 이 NetBIOS 명명 관례에서는 IP 주소가 이미 데이터그램 서비스에 필요한 이름을 내어준다는 것만 말합니다. 엔지니어는 조회 하나가 사라진 것은 감탄할 수 있지만, 모든 하위 계층 질문이 사라졌다고 주장해서는 안 됩니다.

브로드캐스트 이름과 명시적 생략

RFC 1088은 브로드캐스트에 고유한 정확한 관례를 부여합니다. 브로드캐스트 인터넷 주소는 NetBIOS 그룹 이름IP.FF.FF.FF.FF를 사용합니다. 이 문서는 그다지 유용한 부정 진술을 합니다. NetBIOS 그룹 이름을 통한 IP 멀티캐스트 주소 지원은 시도하지 않는다는 것입니다. 이 문장은 각주가 아닙니다. 이름 표의 요령이 어디까지 일반화되지 않는지 운영자에게 알려 줍니다.

같은 규율이 512바이트 최대 전송 단위에도 나타납니다. NetBIOS 데이터그램은 최대 512바이트의 데이터를 운반하므로 IP-over-NetBIOS의 MTU도 그렇습니다. 그런 호스트와 통신하는 호스트는 단편 재조립이 필요할 수 있습니다. 이 한도는 매핑의 실패로 단편화를 만들지 않습니다. 운반체의 상한이 가져오는 결과일 뿐입니다. 다만 추적이 별개의 사실들을 별개로 유지해야 함을 의미합니다. 도출된 목적지 이름, 전송된 데이터그램, 단편들, 재조립된 IP 데이터그램은 서로 교환할 수 있는 관찰이 아닙니다.

조건부 라우터는 추론된 경로가 아니다

RFC 1088은 IP를 일반 데이터 링크 프로토콜과 NetBIOS 데이터그램 모두로 캡슐화할 수 있는 라우터가 있다면, 이러한 NetBIOS 호스트들이 더 넓은 인터넷과 통신할 수 있게 해 준다고 말합니다. 이 문장은 조건부이며 그 조건이 중요합니다. 그런 능력을 갖춘 라우터가 가능하게 만들 일을 서술합니다. 특정 라우터가 배치되었다는 증거도, 특정 호스트가 전역 도달 가능성을 가졌다는 증거도, 어느 주소에 경로를 사용할 자격이 있는 소유자가 있었다는 증거도 아닙니다.

이것이 가장 깔끔한 형태의 역사적 교훈입니다. 인터넷은 다른 모든 제도적·기술적 질문을 해결하지 않고도 구현할 수 있는 작은 인터페이스에 합의함으로써 성장했습니다. RFC 1088은 주소를 하나의 데이터그램 서비스에 판독 가능하게 만들었습니다. 판독 가능성을 권위로 바꾸지는 않았습니다. 모니터링 시스템이IP.XX.XX.XX.XX를 '엔드포인트 확인됨'으로 바꾸는 순간, RFC가 기계 밖에 신중히 남겨 둔 결론을 하나 덧붙인 것입니다.

기록의 출처와 한계

아래의 RFC들은 1989년 명세, 그 주소·이름 관례, 명시된 한계, 그리고 IP, 서브네팅, ARP를 둘러싼 관련 구분들을 확립합니다. 이들은 현재의 배치, 특정 호스트의 구성, 현재 도달 가능성, 소유권, 신원, 권한 부여, 패킷 전달 또는 애플리케이션 성공을 확립하지 않습니다.