요약

  • RFC 3678은 기존 멀티캐스트 멤버십 호출을 소스 및 바이너리 호환성을 위해 유지한 뒤, 기존 인터페이스를 바꾸는 대신 소스 필터 옵션과 함수를 추가했습니다.
  • 델타 호출은 현재 필터에서 소스 하나를 변경합니다. 전체 상태(full-state) 호출은 모드와 목록을 함께 교체하며, RFC 3678은 그룹에 가입한 채 모드를 바꾸기 위해 이 형태가 필요하고 목록이 클 때 변경이 원자적으로 이루어진다는 점에서 유용하다고 설명합니다.

기존 호출을 확장할 수는 없었다

첫 번째 제약은 라우터가 아니었습니다. 소켓을 이미 사용 중이던 프로그램이었습니다. 소스 필터링 이전에 멀티캐스트 수신자는 그룹에 가입하고, 필요하면 로컬 인터페이스를 선택할 수 있었습니다. 이로써 멤버십은 성립하지만 애플리케이션이 어떤 발신자를 원하는지 설명할 방법은 없었습니다. 확립된 호출 자체를 바꾸는 것은 누락된 정보를 추가하는 안전한 방법이 아니었습니다. RFC 3678은 이러한 인터페이스는 바이너리 호환성이 깨지지 않고는 변경할 수 없다고 밝힙니다.

그래서 문서는 추가적(additive) 경로를 택했습니다. 새 API는 소스 호환성—기존 소스 코드가 그대로 컴파일되고 동작함—과 바이너리 호환성—기존 실행 파일이 확장을 지원하는 시스템에서 계속 실행됨—을 모두 보존하도록 요구했습니다. 또한 변경을 최소화하고, 애플리케이션이 새 옵션을 사용할 수 없을 때 이를 인지하고 우아하게 대응하는 방법을 마련하도록 했습니다. 이는 API 설계 메모이며, 모든 운영체제가 동일한 호출을 구현했다는 증거가 아닙니다.RFC 3678

한 번에 소스 하나씩

델타 인터페이스는 필터를 점진적으로 변경합니다. any-source 멀티캐스트 멤버십에서 수신자는 기본적으로 모든 소스를 수용하는 상태로 시작하고, 차단(block) 또는 차단 해제(unblock) 연산이 발신자 하나의 처리 방식을 바꿉니다. source-specific 멀티캐스트에서는 수신자가 원하는 집합에서 특정 소스를 추가하거나 제거합니다. 호출 이전 상태가 중요합니다. RFC는 특정 옵션/멤버십 조합을 유효하지 않은 것으로 정의하며, 이미 차단된 소스나 가입하지 않은 소스는 다른 오류를 낼 수 있습니다.

애플리케이션이 작은 변경 하나를 하려 할 때 이는 경제적인 문법입니다. 나머지 목록을 다시 제출하지 않고도 “이 소스를 차단하라” 또는 “이 소스에 가입하라”라고 말할 수 있습니다. 다만 그 의미는 현재 필터와 멤버십 상태에 묶여 있습니다. 이 연산은 델타이지, 그 이후 필터가 무엇이어야 하는지에 대한 완전한 선언이 아닙니다. API 표면에는IP_ADD_SOURCE_MEMBERSHIP같은 IPv4 전용 옵션과MCAST_JOIN_SOURCE_GROUP같은 프로토콜 독립 옵션이 포함됩니다.RFC 3678

아니면 전체 상태를 교체한다

전체 상태(full-state) API는 다른 역할을 합니다. 필터 모드—MCAST_INCLUDE또는MCAST_EXCLUDE—와 포함하거나 제외할 전체 소스 목록을 함께 공급합니다. 이 호출은 멤버십 변경 하나를 적용하는 대신 기존 필터를 교체합니다.

RFC 3678은 이 구분이 중요한 두 경우를 명시합니다. 그룹에서 탈퇴하지 않고 INCLUDE와 EXCLUDE 사이를 전환해야 하는 애플리케이션은 전체 상태 API를 사용해야 합니다. 소스 목록이 큰 애플리케이션도 그렇습니다. 목록을 한 번의 연산으로 원자적으로 바꿀 수 있기 때문입니다. 일련의 델타 연산이 결국 같은 집합을 기술할 수 있지만, 전체 상태 형태는 중간 편집의 연속이 아니라 하나의 교체를 표현합니다.

게터(getter)에는 자체 계약이 있습니다. 애플리케이션은 버퍼 크기 추정치를 제공하고 전체 소스 개수를 받으며, 버퍼가 너무 작으면 호출을 반복할 수 있습니다. 구현체가 목록 최대 크기를 제한한다면 그 한도를 넘는 집합은ENOBUFS로 실패할 수 있습니다. 이런 세부 사항 때문에 “전부 교체”는 무제한 용량의 약속이 아니라 상태 관리 도구입니다.RFC 3678

하나의 그룹, 두 주소 패밀리

이 메모는 IPv4 소스 코드를 최소한만 수정하려는 애플리케이션을 위해 IPv4 전용 구조체와 옵션을 유지했습니다. 동시에 프로토콜 독립 형태도 정의했습니다. 이들은 주소 패밀리를 지원하는 소켓 구조체에 그룹과 소스를 담으면서, 로컬 인터페이스는 별도로 인터페이스 인덱스로 식별합니다. RFC 3493이 IPv6 소켓 어휘의 상당 부분을 제공했지만 프로토콜 독립적인 멀티캐스트 가입·탈퇴 연산은 없었고, RFC 3678이 그 공백을 채웠습니다.RFC 3493

이 구분은 함수 시그니처에서 간과하기 쉽습니다. 그룹 주소는 멀티캐스트 목적지를, 소스 주소는 발신자를 명명하고, 인터페이스 인덱스는 연산을 로컬 접속 범위로 한정합니다. 검증된 기술 정오표 2524는 이후 5.2.2절의 게터 인수 설명을 “로컬 IP 주소”에서 “인터페이스 인덱스”로 바로잡아 한 절 앞의 세터와 일치시켰습니다. 별도의 검증된 편집 정오표는 오류 코드 절에 대한 상호 참조를 수정했습니다. 어느 정오표도 소스 필터 모델을 바꾸지는 않으며, 둘 다 인수가 실제로 의미하는 바를 보존하는 데 기여합니다.RFC 3678 정오표

여기의 필터링이 곧 모든 곳의 필터링은 아니다

라우터가 IGMPv3나 MLDv2를 지원하지 않더라도 소스 필터는 호스트 안에서 동작할 수 있습니다. 따라서 애플리케이션은 원치 않는 패킷이 로컬 링크를 통과하는 것이 막혔음을 입증하지 않고도 로컬 필터링을 얻을 수 있습니다. 프로토콜들은 필터 정보를 라우터 쪽으로 전달합니다. 이는 소켓 호출과 별개의 메커니즘이며 자체적인 상태와 경로를 갖습니다. RFC 3376, RFC 3810, RFC 4604는 이 네트워크 측 동작의 일부를 기술합니다.RFC 3376RFC 3810RFC 4604

필터링은 발신자를 인증하지도 않습니다. RFC 3678은 소스 필터링만으로는 허용된 소스처럼 위조된 소스 주소를 가진 패킷을 막을 수 없다고 경고합니다. 역경로 검사가 일부 라우팅 구성에서 도움이 될 수 있지만 보장은 아닙니다. 소켓 호출이 성공했다는 것은 API 연산에 대한 증거이지, 라우터 상태, 대역폭 감소, 인증된 트래픽, 패킷 수신 또는 애플리케이션 성공의 증명이 아닙니다.RFC 3678

이 문서는 Informational 문서이며 인터넷 표준이 아니라고 명시하고 있습니다. 또한 공식 소켓 사양을 독자에게 안내합니다. 역사적 기여는 더 좁고 실용적입니다. 기존 멤버십 호출을 보호하고, 소스 단위 변경은 저렴하게 유지하면서도 상태나 규모가 요구할 때는 전체 필터를 한 단계로 교체할 수 있게 했다는 것입니다. Lu Heng의 후속 노트 64와 65를 통해 읽어 보면, 이는 호환성과 로컬 채택을 설계의 렌즈로 본 사례이며, 그가 2004년 이 메모를 저술했다거나 승인했다거나 영향을 주었다는 주장이 아닙니다.RFC 3678 상태노트 64노트 65

출처