요약
- IGMPv1과 v2는 무작위 타이머로 리포트 전송 시점을 분산한 뒤, 다른 멤버의 동일한 리포트를 들은 호스트가 자신의 대기 중 Membership Report를 취소하도록 했다. 라우터는 보통 그룹·링크당 사실 하나만 학습했다: 최소 한 명의 수신자가 존재한다는 사실.
- IGMPv2는 Leave 메시지가 짧은 그룹별 질의 시퀀스를 트리거하도록 만들었지만, 한 명의 탈퇴를 그룹이 비었다는 증거로 취급하지 않았다. IGMPv3는 나중에 소스 목록, 상태 변화, 스위치 포트 포워딩 때문에 서로 다른 호스트의 리포트가 더 이상 서로 호환 가능하지 않게 되어 호스트 리포트 억제를 제거했다.
단순한 질문 다음에 오는 위험한 순간
바쁜 로컬 네트워크에 붙어 있는 멀티캐스트 라우터는 겸손한 질문을 가지고 있다: 이 링크로 어떤 멀티캐스트 그룹의 트래픽을 계속 포워딩해야 하는가? 명백한 절차는 모든 호스트에게 물어 모든 답을 기다리는 것이다.
그러나 그것은 폭발적인 응답의 조리법이기도 하다. 수백 대의 기계가 같은 Query를 받고 동시에 답하면, 제어 프로토콜 자신이 피하려던 혼잡을 만들어 낸다. 그렇다고 상시 대표자를 임명하면 또 다른 문제가 생긴다. 그룹 멤버십은 동적이고 인터페이스에 붙어 있으며 중앙 멤버가 소유하지 않는다.
RFC 1112는 1989년 8월에 발행되어 리더를 지명하지 않고 이 문제를 해결했다. 그 설계는 라우터가 실제로 얼마나 많은 증거를 필요로 하는지 묻는 데 의존했다. 당시 앞둔 포워딩 결정을 위해 라우터는 호스트 명부를 필요로 하지 않았다. 접속된 네트워크에 그 그룹의 멤버가 최소 한 명 존재하는지만 알면 되었다.
그 작은 질문 덕분에 리포트 하나로 충분했다.
모두가 기다렸지만, 가장 먼저 만료된 타이머만 말했다
IGMPv1 라우터는 IP TTL 1로 전 호스트 주소224.0.0.1에 Host Membership Query를 보냈다. 각 호스트는 Query가 도착한 인터페이스에서 자신의 멤버십을 검토했다. 즉시 답하는 대신, 해당하는 그룹마다 0~10초 사이의 별도 무작위 지연을 정하고 타이머를 시작했다.
이 무작위성이 첫 번째 압축을 수행했다. 리포트는 Query 순간에 동기화되는 대신 구간 전반에 분산됐다. 각 리포트의 목적지가 두 번째 압축을 수행했다. 호스트는 자신이 보고하는 그룹의 멀티캐스트 주소로, 역시 TTL 1로 리포트를 보냈다. 따라서 같은 링크의 그 그룹 다른 멤버들이 그것을 들을 수 있었다.
아직 기다리던 호스트가 자신의 그룹에 대한 유효한 리포트를 들으면 자기 타이머를 멈췄다. 정상적인 경우, 타이머가 가장 먼저 만료된 멤버가 그 그룹의 유일한 리포트를 보냈다. 나머지가 답변에 실패한 것은 아니다. 그들의 침묵은 동등한 증인이 이미 라우터가 필요로 하는 사실을 제공했음을 알리는 규정된 확인이었다.
이 메커니즘은 종종 리포트 억제로 묘사되지만, 그 단어는 정밀함을 가릴 수 있다. 응용 계층이나 호스트에서 멤버십을 억제한 것이 아니다. 하나의 보고 주기 동안 하나의 인터페이스에서 한 그룹의 중복 전송을 억제한 것이다. 또한 첫 리포터가 소유자, 대변인, 접근 권한 기관이 된 것도 아니었다. 그저 무작위 경주에서 이겼을 뿐이다.
존재는 영구 등록부가 아니라 소프트 상태였다
라우터는 주기적 Query로 자신의 지식을 갱신했다. 규정된 질의·타임아웃 절차를 통해 그 그룹의 리포트가 더 이상 오지 않으면, 로컬 멤버가 더 이상 없다고 가정하고 원격에서 시작된 그 그룹의 트래픽을 링크로 포워딩하는 것을 멈출 수 있었다. 따라서 크래시, 상태 손실, 조용한 탈퇴는 내구성 있는 탈퇴 트랜잭션을 요구하지 않았다. 부재는 갱신된 증거가 오지 않은 뒤에 나타났다.
가입은 반대 성향을 사용했다. 그룹에 가입한 호스트는 즉시 요청되지 않은 리포트를 보내고, 손실 가능성을 대비해 짧은 지연 뒤 반복했다. 다음 주기 Query를 기다리지 않았는데, 자신이 그 링크의 첫 로컬 수신자일 수 있고 그렇지 않으면 트래픽이 아예 링크에 도달하지 않을 수 있기 때문이다.
이것은 의도적으로 비대칭인 시스템이었다. 존재는 어떤 멤버든 신속히 알릴 수 있었다. 지속 존재는 한 멤버가 갱신할 수 있었다. 부재는 시간과, 남은 증인을 끌어내려는 실패한 시도가 필요했다.
이 경제성은 결정 대상에서 직접 나온다. 라우터가 '이 링크 어딘가에서 그룹 G가 원한다'는 사실만 저장한다면, G에 대한 두 호스트의 긍정 리포트는 서로 호환 가능하다. 두 번째 리포트를 억제해도 그 결정에 필요한 정보는 하나도 버려지지 않는다.
Leave는 멈추라는 증거가 아니라 물어보라는 증거였다
RFC 2236은 1997년 11월에 IGMPv2를 도입했다. 명시적 Leave Group 메시지, Query에 실리는 Max Response Time, 그룹별 Query, 공용 쿼리어 선출 규칙을 추가했다. 요점은 더 낮은 leave 지연이었다: 마지막 수신자가 떠난 뒤 원치 않는 포워딩을 더 빨리 멈추는 것.
프로토콜은 한 호스트가 무엇을 증명할 수 있는지 신중했다. 탈퇴하는 호스트는 자신이 그 그룹의 Query에 마지막으로 답한 호스트였음을 기억하고 있을 때만 Leave를 보내야 했다. 마지막 리포터가 아니었던 호스트는 아무것도 보내지 않을 수 있었다. 다른 멤버가 최근에 존재의 증거를 제공했기 때문이다.
마지막 리포터의 Leave조차 즉각 삭제를 승인하지 않았다. 쿼리어는 설정된 횟수의 Group-Specific Query를 짧은 간격으로 보냈다. 다른 멤버가 남아 있으면 응답하고 그룹 상태를 보존할 수 있었다. 최종 응답 구간 이후 리포트가 오지 않아야 라우터는 그 링크에 그 그룹의 멤버가 없다고 결론 내렸다.
따라서 Leave는 "이 전제를 지금 다시 검증하라"는 뜻이었다. "떠나는 기계를 모두의 대변인으로 신뢰하라"는 뜻이 아니었다. 설계는 한 명의 탈퇴와 집합적 부재 사이의 구분을 보존하면서 대기 시간을 줄였다.
하위 호환성이 이 경계를 드러냈다. IGMPv1 멤버가 있으면 v2 라우터는 해당 그룹에 대한 Leave 메시지를 무시한다. 오래된 호스트는 v2 탈퇴 절차를 구현하지 않기 때문이다. 새로운 빠른 경로가 낡은 참여자의 침묵을 안전하게 재해석할 수는 없었다.
소스 필터링이 리포트끼리 서로 다르게 만들었다
2002년RFC 3376으로 발표되고 현재RFC 9776에 규정된 IGMPv3는 질문 자체를 바꿨다. 수신자는 그룹 G 트래픽을 나열된 소스에서만(INCLUDE 모드), 또는 목록에 없는 모든 소스에서(EXCLUDE 모드) 요구할 수 있었다. 로컬 시스템은 소켓 요청을 인터페이스 상태로 결합했고, 리포트가 그 소스 목록을 실을 수 있었다.
라우터 상태는 더 이상 단순한 그룹 G가 아니었다. 그룹 더하기 소스 상태의 문제가 되었다. v3 리포트는 현재 상태, 필터 모드 변경, 새로 허용된 소스, 차단해야 할 소스를 기술할 수 있었다. 같은 링크에 붙은 두 호스트가 합법적으로 서로 다른 발신자를 원할 수 있었다. 첫 리포트는 그 차이를 잃으면서 두 번째를 대신할 수 없었다.
그래서 v3 설계 근거는 호스트 Membership Report 억제를 제거했다. 호스트는 더 이상 다른 호스트의 유사한 전송을 관찰했다는 이유만으로 자신의 v3 리포트를 취소하지 않는다. 표준은 여러 이유를 기록한다: 라우터가 빠른 leave나 어카운팅을 위해 호스트별 관찰을 필요로 할 수 있고; 스누핑 브리지가 억제를 곤란하게 만들었고; 취소 상태를 없애면 호스트가 단순해지고; 단일 v3 패킷이 여러 그룹의 레코드를 묶을 수 있어 별개의 상태를 지우지 않고도 효율을 회복할 수 있었다.
이 반전이 페이싱을 버린 것은 아니다. 호스트는 여전히 응답을 Max Response Time 전반에 분산하고 General Query에 즉시 답해서는 안 된다. 동시 응답 문제는 그대로 남는다. 사라진 것은, 남의 전송을 들으면 자신의 증거가 불필요해진다는 추론이었다.
스위치드 LAN은 더 이상 하나의 음향 방이 아니었다
원래의 억제 알고리즘은 공유 보고 환경을 가정했다: 그룹 멤버가 자신을 침묵시키는 리포트를 엿들을 수 있었다. 이더넷 스위칭은 그 가정을 복잡하게 만들었다.
평범한 브리지는 멀티캐스트를 플러딩하지만, IGMP 스누핑 스위치는 멤버십 메시지를 검사해 포트별 포워딩 상태를 만든다.RFC 4541은 그 결과로 생긴 긴장을 문서화한다. 스누핑 스위치는 보통 Membership Report를 호스트 전용 포트로 플러딩하지 않고 라우터 포트 쪽으로 전달한다. 리포트를 플러딩했다면, 다른 포트의 v1 또는 v2 호스트가 그것을 듣고 자기 리포트를 취소할 수 있었다. 라우터는 그룹 존재라는 하나의 사실을 갖지만, 스위치는 침묵한 호스트의 포트도 멀티캐스트 스트림이 필요하다는 사실을 영영 학습하지 못할 수 있었다.
이 최적화는 경계를 넘어선 것이었다. 라우터의 그룹당 링크 결정에는 한 증인이 충분했다. 스위치의 그룹당 포트 결정에는 증인들이 서로 호환 가능하지 않았다. IP 제어 계층에서 절약한 리포트가 계층 2의 누락된 포워딩 항목이 될 수 있었다.
IGMPv3가 모든 네트워크 장비를 전지적으로 만든 것은 아니다. 그것은 이제 소비되는 더 세밀한 증거에 보고 규칙을 맞춘 것이다. 리포트는 v3 지원 멀티캐스트 라우터가 듣는224.0.0.22로 이동했고, 여러 Group Record를 실을 수 있었다. 스누핑 장비는 여전히 올바른 버전 처리, 타임아웃, 토폴로지 변화 동작을 필요로 한다.
호환성은 침묵의 낡은 의미를 보존했다
버전 전환은 하나의 깨끗한 날짜에 링크별로 일어나지 않는다. IGMPv3 시스템은 오래된 Query를 들은 뒤 호환성 상태를 유지하고 필요하면 v1 또는 v2 리포트를 보낼 수 있다. 라우터 역시 오래된 멤버를 추적한다. 그들의 존재가 Leave와 소스별 상태의 안전한 해석을 바꾸기 때문이다.
즉, 회선상의 버전은 장식적 메타데이터가 아니다. 오래된 참여자 하나가 타임아웃 구간 동안 그룹 전체를 낡은 증거 의미론으로 되돌릴 수 있다.RFC 4607의(S,G)채널 모델로 정의된 Source-Specific Multicast에서 소스별 증거가 사라지면 원치 않는 소스에서 트래픽이 오거나 의도된 프루닝이 막힐 수 있다. 현재 v3 표준은 그에 따라 SSM 인지 호스트는 자신의 v3 멤버십 레코드가 더 오래된 리포트로 억제되어서는 안 된다고 규정한다.
버전 호환성은 마이그레이션 중 도달성을 보존하므로 유용하다. 그러나 운영 비용도 만든다: 가장 표현력이 낮은 참여자가 링크가 안전하게 사용할 수 있는 구분을 결정할 수 있다.
리포트는 결코 권한이 되지 않았다
IGMP의 증거는 여전히 좁다. 그것은 시스템들과 인접 멀티캐스트 라우터 사이의 IPv4 멀티캐스트 수신 관심을 신호할 뿐이다. 광역 멀티캐스트 트리를 만들지 않고, 누가 전송할 수 있는지 선택하지 않고, 구독자를 인증하지 않고, 패킷 전달을 보장하지 않고, 내구성 있는 신원을 수립하지 않는다.
RFC 9776은 IGMP가 기밀성을 제공하지 않는다고 말한다. 링크상 장비는 잠재적으로 민감한 그룹 관심을 관찰할 수 있다. 위조 리포트는 실제 수신자가 없는 곳에서 트래픽을 계속 흐르게 할 수 있고, 위조된 구버전 리포트는 라우터를 빠른 leave나 소스별 처리를 약화시키는 호환 모드에 묶어둘 수 있다. TTL 1, Router Alert 규칙, 온링크 소스 검사가 일부 공격 경로를 제한하지만, 암호학적 증명은 아니다.
이 한계는 숨길 결함이 아니라 역사의 일부다. IGMP는 라우팅에 필요한 최소한의 로컬 증거를 표준화함으로써 성공했고, 권한 부여와 응용 신원은 다른 곳에 남겼다. 문제는 포워딩 힌트가 사람, 자격, 전달 결과에 대한 주장으로 승격될 때 시작된다.
출처와 한계
RFC 1112는 v1의 무작위 타이머와 엿들은 리포트 취소를 정의한다. RFC 2236은 v2의 Leave 처리, 마지막 멤버 질의, 구버전 공존을 정의한다. RFC 3376은 2002년 v3 근거를 기록하고, RFC 9776은 현재 하위 호환 v3 표준이다. RFC 4541은 스누핑 스위치에 대한 정보성 지침을 제공하고, RFC 4607은 소스별 서비스 모델을 정의한다.
이 기록들은 프로토콜 메커니즘을 확립할 뿐, 채택률, 제품 적합성, 단일 보편적 스위치 동작, 어떤 수신자의 신원도 확립하지 않는다. 억제의 종료를 증거의 가치 변화로 읽는 것은 표준들의 상태 모델과 명시된 근거에서 나오는 추론이다.
회원 브리핑
프로필 심층 컨텍스트
올바른 멤버십 등급으로 로그인하면 전체 브리핑과 출처 노트를 볼 수 있습니다.
Strategic Circle 전용
Strategic Circle
모든 독자에게 공개됩니다. 가입 후 로그인하면 프로필 브리핑를 열람할 수 있습니다.
Strategic Circle 가입하기Leadership Alliance 전용
Leadership Alliance
자격을 갖춘 IP 자산 소유자 및 운영진을 위한 콘텐츠입니다. 로그인하면 Leadership Alliance 브리핑을 열람할 수 있습니다.
Leadership Alliance 가입하기





