요약

  • IPv4 옵션 136은 스트림 개념을 이해하지 못하는 네트워크를 통과하면서 하나의 16비트 SATNET 스트림 식별자를 전달했습니다.
  • 호스트와 라우터 표준이 먼저 이 필드가 동작을 일으키지 못하도록 막았고, 이후 정식 폐기와 필터링 지침이 은퇴 절차를 완성했습니다.

4옥텟으로 완결된 메커니즘

RFC 791은 Stream Identifier에 가변 목록이나 포인터를 두지 않았습니다. 첫 옥텟은 타입 136, 두 번째는 고정 길이 4를 선언했고, 마지막 두 옥텟은 16비트 Stream ID를 담았습니다. 그 목적은 좁았습니다. 스트림을 지원하지 않는 네트워크를 통과하면서 SATNET 스트림 식별자를 전달하는 것입니다.

이 옵션의 복사 비트는 설정되어 있었습니다. IPv4 데이터그램이 분할되면 모든 조각이 식별자를 물려받습니다. 최대 한 번만 나타날 수 있었습니다. 이러한 규칙은 자신의 의미 체계를 갖지 못한 인프라를 통과하면서도 살아남도록 설계된 레이블에는 자연스러운 것이었습니다. 중간 노드가 스트림을 이해할 필요 없이 값은 계속 붙어 있을 수 있었습니다.

그런 간결함은 곧 의존성을 드러냅니다. 이 4바이트는 독립적인 스트림 시스템이 아니라 전달만을 정의했습니다. 그 안에는 협상, 할당 절차, 검증 또는 대체 의미가 없었습니다. SATNET 스트림 개념이 운영적으로 무의미해지자, 옵션 자체에서 일반적인 인터넷 용도를 발견할 여지는 남지 않았습니다.

정식 은퇴 이전의 낡음

RFC 1122 시점에 이미 호스트 측 규칙은 명확했습니다. Stream Identifier는 폐기된 것으로, 전송해서는 안 되고(SHOULD NOT), 수신 시 무음으로 무시해야 합니다(MUST). RFC 1812는 같은 정리를 라우터로 가져왔습니다. 라우터는 이를 발생시키지 않아야 하고, 로컬에서 수신하면 무시해야 하며, 포워딩되는 패킷에 존재할 경우 값을 아무렇게도 처리하지 않은 채 그대로 통과시켜야 합니다.

무시와 보존은 모순이 아니었습니다. 전자는 죽은 의미 체계가 현재 동작을 지배하지 못하게 했고, 후자는 낡았지만 형식이 온전한 필드가 우연한 포워딩 실패로 이어지지 않게 했습니다. 호환성은 관성으로 축소되어 있었습니다.

RFC 6814는 2012년, IPv4 옵션 레지스트리 정리의 일환으로 Stream ID를 마침내 정식 폐기했습니다. 이어 RFC 7126은 현재의 사용 사례가 없고, 알려진 구체적 보안 문제도 없으며, 차단해도 상호운용성 비용이 없다고 기술했습니다. 따라서 그 운영 권고는 진단용 옵션보다 단순했습니다. 라우터, 게이트웨이, 방화벽은 이를 포함한 패킷을 폐기해야 합니다.

출처