요약

  • SSM은 그룹만 지정하는 요청을 채널 요청(S,G)로 바꾸어, 수신자가 멀티캐스트 그룹뿐 아니라 송신자까지 지정하게 한다.
  • 이로써 SSM 경로에서 공유 트리와 랜더부스 장비가 제거되지만, 소스 발견은 애플리케이션으로 옮겨가고 지정된 송신자를 인증하지는 않는다.
  • RFC들은 강력한 인터도메인 권고를 뒷받침하지만, 모든 네트워크 내부에서 ASM이 사라졌거나 SSM이 보편적으로 배포되었다는 주장은 아니다.

추가 좌표

전통적인 멀티캐스트 표현은 속기 쉬울 만큼 단순한 그림을 떠올리게 한다. 애플리케이션이 그룹G에 가입하면 네트워크가 그 주소 뒤에 어떤 소스들이 속하는지 알아낸다는 것이다. 소스 지정 멀티캐스트(SSM)는 요청 자체를 바꾼다. RFC 4607에 따르면 서비스는(S,G)로 식별되는 채널이다. 호스트는 소스 주소S에서 SSM 목적지 주소G로 전송된 데이터그램을 받겠다고 요청하며, 다른 소스에서 온 데이터그램은 그 구독을 충족하지 못한다.

이 추가 좌표가 아키텍처다. IPv4는 SSM 의미론을 위해232.0.0.0/8을 예약하고, IPv6는FF3x::/32를 사용한다. 라우터는 이 범위를 일관되게 처리해야 한다. SSM 주소에 대한 비소스 지정(*,G)요청은 올바른 요청의 근사 버전이 아니다. RFC 4607은 그러한 요청을 사용하거나 전파해서는 안 된다고 말한다. 한 라우터가 그 주소를 소스 지정으로 처리하고 다른 라우터가 일반 그룹 멤버십으로 기대하면, 주소의 의미가 경로를 따라 갈라진다.

중요한 권한 이전은 놓치기 쉽다. 패킷은 여전히 멀티캐스트처럼 보이기 때문이다. 애니소스 멀티캐스트(ASM)에서는 소스 발견이 네트워크 기능이 될 수 있다. SSM에서는 수신 애플리케이션이 다른 메커니즘으로 소스를 알아내 호스트에 전달해야 한다. 네트워크는 엣지에서 이미 내린 선택을 보존하도록 요구받는다.

더 단순한 경로, 새로운 의존성

RFC 8815는 운영자 측의 논지를 분명히 한다. 인터도메인 멀티캐스트에서는 ASM을 폐기 권고하고 SSM을 권장하며, 호스트와 라우터의 완전한 지원을 요구한다. SSM 경로에는 랜더부스 포인트(RP), 공유 트리, 최단 경로 트리로의 전환, PIM 레지스터 메시지, MSDP, 동적 RP 발견이 필요 없다. 수신자의 소스 지정 조인은 PIM-SSM을 사용해 지정된 소스를 향한 상태를 구축할 수 있다.

이는 표기만 깔끔해진 것이 아니라 실제 단순화다. 네트워크가 소스를 발견하고 조정하도록 돕는 것만을 목적으로 하던 구성 요소가 제거된다. 그러나 소스가 스스로 발견되는 것은 아니다. 의존성은 수신자에게 어떤S를 요청할지 알려 주는 애플리케이션 계층 채널로 옮겨갔다.

따라서 오래된 편성표, 침해된 제어 서비스, 운영자 실수는 잘못된 소스를 선택할 수 있으며, 그래도 멀티캐스트 네트워크는 그 선택을 완벽하게 강제할 수 있다. 이 문장은 분석이지 RFC가 한 주장이 아니다. 표준은 대역 외 발견 요구 사항을 정립하며, 운영상의 결과는 결정이 이제 어디에 있는지에서 따라온다.

RFC 8815는 권고의 경계도 긋는다. 인터도메인 멀티캐스트에 대해 ASM을 폐기 권고할 뿐, 하나의 조직이나 관리 도메인 내부에서 ASM을 배제하지는 않는다. 이 BCP는 관리 경계에서의 아키텍처 방향이지, 모든 기존 멀티캐스트 배포가 이미 이전했다는 증거가 아니다.

호스트가 선택을 보존해야 한다

RFC 4604는 이 모델을 IGMPv3와 MLDv2에 매핑한다. 소스 지정 애플리케이션 요청은 호스트 API, 호스트 IP 모듈, 첫 홉 신호, 라우터 상태를 거쳐 살아남아야 한다. SSM 범위 주소에 대한 비소스 지정 요청은 실패해야 한다. 구버전 호환성 때문에 요청된(S,G)채널이 전달되지 않을 수도 있다. 레거시 보고서가 소스 지정을 담을 수 없기 때문이다.

공유 링크에서는 더 날카로운 실패가 있다. RFC 4604가 설명하는 레거시 호환 조건에서 SSM 인식 호스트는 다른 호스트의 보고를 들었다는 이유만으로 자신의 소스 지정 보고를 억제해서는 안 된다. 억제하면 첫 홉 라우터가 필요한 소스 필터를 학습하지 못하고 링크의 다른 수신자에게 서비스가 거부될 수 있다. 중복 잡음처럼 보이는 것이 구버전 보고에 없는 수용 정보를 나르고 있다.

링크 계층 전달도 일을 끝내지 않는다. 이더넷에서 링크 계층의 멀티캐스트 목적지는 IP 소스로 패킷을 선택하지 않는다. 따라서 RFC 4607은 호스트 IP 모듈에 필터링 의무를 남긴다.(S,G)를 요청한 소켓에 데이터그램을 전달하기 전에 소스를 확인해야 한다. SSM은 경로 전체의 합의이지, 영리한 라우터 기능 하나가 아니다.

선택은 인증이 아니다

S를 지정하면 수용 범위가 좁아진다. 그것이S를 누가 제어하는지 증명하지는 않는다. RFC 4607은 위조된 소스 주소가 서비스 모델을 위반할 수 있다고 명시적으로 경고하며, 강한 인증이 필요한 애플리케이션에는 상위 계층 메커니즘이 필요하다고 말한다. 구분은 정확하다. SSM은 수신자에게 네트워크 계층의 소스 선택을 제공하지만, 암호학적 송신자 신원을 제공하지는 않는다.

같은 RFC는 또 다른 편안한 과장도 배척한다. SSM이 멀티캐스트 상태나 서비스 거부 위험을 없애지는 않는다. 각 구독은 라우터 상태, 처리, 제어 트래픽을 만들 수 있다. 매우 큰 구독 집합은 공격 표면이 될 수 있으며, 사양은 신중하게 선택된 속도 제한이나 상태 제한을 허용한다. 랜더부스 인프라를 제거하는 설계도 노출하는 수용 인터페이스를 통해 고갈될 수 있다.

증거가 보여 주지 않는 것

이 세 RFC는 의미론, 호스트 동작, IETF의 인터도메인 권고를 정의한다. 지역별 또는 운영자 유형별 현재 SSM 점유율을 측정하지는 않는다. 벤더 기본값, 이전 결함, 특정 서비스가 소스 발견 채널을 보호하는지도 확립하지 않는다. 이전 후 대역폭, 인시던트, 상태 감소를 정량화하지도 않는다. 그런 주장에는 이 고정된 출처 집합 밖의 증거가 필요하다.

출처가 확립하는 것으로 충분한 것은 더 좁은 결론이다. SSM은 ‘그룹에 가입한다’는 말이 완전한 지시로 남는 것을 거부함으로써 네트워크를 단순화한다. 수신자는 송신자를 지정해야 하고, 호스트와 라우터는 그 선택을 보존해야 하며, 애플리케이션은 그 선택을 발견할 책임을 받아들여야 한다. 네트워크를 더 쉽게 추론할 수 있게 되는 것은 바로 이전의 질문 하나가 엣지로 돌아갔기 때문이다.

출처