요약

  • RFC 9947은 실험용 Alternate-Marking SRH TLV를 제어된 SR 도메인 안으로 한정하면서, 자발적 라이브 네트워크 배포의 결과를 Independent Submissions Editor 또는 IETF SPRING 워킹 그룹과 공유할 것을 기대합니다. 패킷 포함과 증거 공개는 서로 다른 제어 문제입니다.
  • 신뢰할 수 있는 결과에는 간결한 증거 반출 기록이 필요합니다. 공개 권한, 정확한 프로토콜 및 구현 버전, 코드 포인트, 테스트된 필드 부분집합, 비교 기준선, 장비 코호트, 샘플링과 불확실성, 부정적 발견, 프라이버시 변환, 아티팩트 해시와 정정 사항 — 단, 원시 트래픽, 고객 신원 또는 악용 가능한 토폴로지는 공개하지 않습니다.

방화벽은 패킷은 막지만 추론은 막지 못한다

RFC 9947은 명확한 운영 경계를 긋습니다. Alternate-Marking 실험은 SR 도메인에 해당하는 제어 도메인 안에서만 실행되어야 합니다. 노드는 로컬에서 관리됩니다. 한 운영자가 이 기능을 설정할지, 어떻게 설정할지를 결정합니다. 실험용 TLV를 실은 패킷은 들어오거나 나가는 것이 차단됩니다. 참여자는 실험 범위 124–126에서 값을 조율하여 한 시험이 다른 시험과 충돌하지 않도록 합니다.

이 경계는 합리적입니다. 이 제안은 RFC 9343의 표준 트랙 방식에 대한 대안으로 IETF 밖에서 개발되었습니다. IETF 합의를 거치지 않았고, IANA 조치를 만들지 않으며, 기존 명세를 대체하지도 않습니다. 실험 확장은 참여자들이 그 의미를 조율한 환경 밖으로 새어 나가서는 안 됩니다.

그러나 이 실험은 외부로 향하는 결론을 만들기 위해 존재합니다. RFC 9947은 결과가 수집되어 Independent Submissions Editor 또는 SPRING 워킹 그룹에 Internet-Draft로 공유될 것을 기대합니다. 초기 결과는 발행 후 2년 이내에 나올 것으로 예상됩니다. 문서 자체가 이 긴장을 인정합니다. 패킷 경로를 따라 수집된 성능 모니터링 데이터는 공유하기 어려울 수 있기 때문에 단일 서비스 제공자 배포를 예상한다는 점입니다.

따라서 패킷과 결론은 서로 다른 경계를 갖습니다. 경계 라우터는 전자를 거부할 수 있습니다. 그러나 그 패킷에서 파생된 차트가 고객, 토폴로지, 아키텍처 약점 또는 공개 검토를 뒷받침하는 최소한의 방법론을 노출하는지는 결정할 수 없습니다. “실험 패킷이 도메인을 벗어나지 않았다”는 것은 보안 서술입니다. 공개 승인은 아닙니다.

결과는 실제 대안을 선택하기 위한 것이다

이 실험의 답을 “기능이 동작했다”로 줄일 수 있는 실험이 아닙니다. RFC 9947은 Alternate-Marking 데이터를 SRH에 넣는 것이 RFC 9343에 따라 IPv6 확장 헤더에 실는 것보다 성능이 더 좋은지 나쁜지를 묻습니다. TLV가 네트워크 전체에서 살아남는지, 처리가 Destination Option보다 빠른지 느린지, 효과가 장비 아키텍처에 따라 달라지는지, 일반적인 SRv6 프로그래밍이 여전히 올바르게 동작하는지, 확장 필드가 다른 온패스 텔레메트리와 어떻게 비교되는지를 묻습니다.

이 질문들에는 분모가 필요합니다. 처리 비용이 더 낮다는 주장은 비교 대상 구성, 패킷 크기, 활성화된 기능, 트래픽 클래스, 제공 부하와 장비 코호트가 없다면 거의 의미가 없습니다. 생존 범위가 더 넓다는 주장에는 경로 형태, 지원·비지원 노드의 수와 역할, 그리고 생존의 정의가 필요합니다. 확장 메타데이터에 대한 운영자의 선호는 무엇이 활성화되었고 어떤 운영 비용이 계산되었는지를 밝혀야 합니다.

RFC 9947은 손실 플래그, 지연 플래그, 20비트 FlowMonID 이상을 허용합니다. 확장 사용은 확장 식별자, 측정 모드, 단편화 상태, 방향, 타임스탬프, 역방향 플로우 설정 정보, 시퀀스 번호를 실을 수 있습니다. 역방향 플로우 제어는 접두어 마스크, 프로토콜, 포트, DSCP, 터널 범위, 주기를 반영할 수 있습니다. 공개 보고서가 원시 값을 하나도 드러내지 않더라도 필드의 조합이 무엇이 측정되었고 어떤 프라이버시 또는 정찰 위험이 관리되어야 했는지를 결정합니다.

그런 선택을 제거한 세련된 평균은 안전해 보이지만 약한 증거입니다. 패킷 캡처는 풍부한 증거지만 무책임한 공개물입니다. 거버넌스 문제는 안으로 남아 있어야 할 운영 세부를 억제하면서 시험의 구조를 보존하는 것입니다.

실험용 코드 포인트는 출처(provenance)의 일부다

TLV 타입은 영구 할당이 아닙니다. 구현체는 실험 범위에서 값을 선택하고, 참여자들 사이에서 그 값을 조율하며, 여러 실험이 충돌 없이 동작할 수 있도록 설정 가능하게 해야 합니다. 그 선택된 값은 공적에 관해 아무것도 말하지 않더라도 결과의 출처에 속합니다.

왜 기록해야 할까요? 후속 검토자가 두 데이터 세트가 같은 와이어 실험을 설명한다는 것을 알아야 하기 때문입니다. 124로 설정된 파서 빌드와 126으로 설정된 장비는 실제로는 조율 오류인 겉보기 실패를 만들어 낼 수 있습니다. 다른 로컬 실험과의 충돌은 관측을 오염시킬 수 있습니다. 어느 경우도 SRH 방식이 열등함을 증명하지 않습니다.

이것은 IANA 코드 포인트가 배포 권한을 부여하지 않는다는 더 넓은 주장과는 구별됩니다. RFC 9947에는 IANA 조치가 전혀 없습니다. 여기서 코드 포인트는 방법 개정판, 빌드, 도메인 구성, 관측 구간을 잇는 조인 키입니다. 이것을 생략하면 외부인이 프로토콜 동작과 실험 설정 실수를 구별하는 연쇄가 끊어집니다.

같은 원칙이 구현 부분집합에도 적용됩니다. 지원하지 않는 TLV를 무시하는 장비는 SRH 처리 규칙에 따라 일관되게 동작하는 것입니다. 모든 세그먼트 엔드포인트가 데이터를 수집할 것으로 기대한 시험은 어떤 엔드포인트가 실제로 그 기능을 지원했고 어떤 SID 동작이 선택되었는지를 식별해야 합니다. 실험에 선택적 확장 필드와 프로그래머블 엔드포인트 동작이 포함되는 한 “구현이 존재한다”는 것은 이항 속성이 아닙니다.

제어 도메인은 정당한 비밀을 담는다

RFC 8799는 한정 도메인 경계를 신뢰가 바뀌는 지점으로 기술합니다. 이 경계는 운영자가 공개하지 않으려는 운영 매개변수도 보호할 수 있습니다. 이는 개별 사용자의 프라이버시와 별개지만, 여기서는 두 이익 모두 중요합니다.

RFC 9343이 이유를 설명합니다. Alternate Marking은 사용자 페이로드를 필요로 하지 않지만, 그 메타데이터는 정찰에 도움이 될 수 있습니다. FlowMonID는 플로우 추적에 도움이 될 수 있고, 결합된 관측 지점은 네트워크 경로 또는 성능 정보를 드러낼 수 있습니다. 모니터링 지점에서 관리 시스템으로 이동하는 통계는 보안 채널을 필요로 합니다. RFC 9341은 무결성 위험을 추가합니다. 공격자는 마킹이나 시간을 조작하고, 수집을 방해하거나, 매우 저속의 은닉 채널을 악용할 수 있습니다.

공개 증거는 잘못된 세분성을 보존할 경우 이러한 위험을 증폭시킬 수 있습니다. 정확한 타임스탬프, 좁은 트래픽 클래스, 장비 위치, 작은 개수는 이름이 제거된 뒤에도 경로의 식별성을 재구성할 수 있습니다. 벤치마크 표는 어떤 아키텍처가 특정 헤더 조합에서 어려움을 겪는지 드러낼 수 있습니다. 토폴로지 다이어그램은 운영자가 민감하다고 여기는 중복성을 노출할 수 있습니다. “익명화됨”은 충분한 방법 서술이 아닙니다.

반대쪽 실수는 기밀성을 이유로 결론만 공개하는 것입니다. 그러면 외부 검토자는 겉보기 이득이 특정 벤더, 특정 소프트웨어 빌드, 한 조용한 구간 또는 실패 사례의 배제에서 나온 것인지 볼 수 없습니다. 제어 도메인은 수사적 방패가 됩니다. 패킷은 안에 남았고 결과는 좋았으니, 우리를 믿으라는 것입니다.

어느 극단도 실험에 도움이 되지 않습니다. 과제는 보호된 데이터 세트를 공개하는 것이 아닙니다. 보호된 관측에서 경계가 설정된 공개 주장으로의 변환을 드러내는 것입니다.

증거 반출 기록

가장 작은 유용한 공개 기록은 권한에서 시작합니다. 운영자 또는 연구 후원자, 공개를 승인한 역할, 제출 목적지와 시점, 그리고 중요한 장비 공급 또는 자금 관계를 명시해야 합니다. ISE는 평가를 받을 수 있고, SPRING은 논의할 수 있습니다. 수신이나 논의는 승인, IETF 합의 또는 표준 트랙 결정이 아닙니다.

다음은 식별입니다. 기록은 RFC 또는 초안 개정판, 구현 빌드, 설정된 실험용 TLV 값, 기본 및 확장 필드 부분집합, SID 동작, RFC 9343 비교 구성을 묶어야 합니다. 아티팩트 해시는 후속 보고서가 같은 방법 번들을 논의하고 있다는 것을 번들 자체를 노출하지 않고 보여줄 수 있습니다.

다음은 모집단입니다. 공개 계층은 악용 가능한 인벤토리를 드러내지 않는 추상화 수준에서 장비 아키텍처와 펌웨어 코호트를 기술해야 합니다. 민감한 위치를 공개하지 않으면서 토폴로지 형태를, 관측 구간, 대상 트래픽, 제외 항목, 샘플 처리, 클록 및 카운터 가정, 손실·지연·지터·생존성·처리 비용에 사용된 정의를 담아야 합니다. 결측 데이터와 신뢰 구간은 미공개 부록이 아니라 평균 옆에 있어야 합니다.

마지막은 결과와 변환입니다. 긍정적, 부정적, 불확실한, 롤백을 유발한 발견이 모두 표현되어야 합니다. 기록은 어떤 플로우, 경로, 시간, 벤더 속성이 집계·편집·억제되었는지, 외부 검토자가 더 이상 재현할 수 없는 것이 무엇인지, 보호된 자료가 있다면 더 좁은 접근 아래에서 검토될 수 있는 것이 무엇인지, 그리고 정정이 이전 공개 주장을 어떻게 대체하거나 한정하는지를 말해야 합니다.

이 기록은 Daniel Kade의 편집 제안이며, RFC 9947이 요구하는 필드 목록이 아닙니다. 데이터 세트보다 작고 보도자료보다 크도록 의도적으로 설계되었습니다. 그 목적은 경계 통과를 감사 가능하게 만드는 것입니다.

실행 코드는 증거이지 판결이 아니다

RFC 7942는 유용하지만 제한적인 유비를 제공합니다. 자발적 Implementation Status 섹션은 Internet-Draft 저자에게 구현의 책임 조직, 이름, 성숙도, 커버리지를 기록하도록 하여 검토자가 실행 코드를 고려할 수 있게 합니다. 나열이 IETF 승인이 아니라는 점을 경고하고 이 정보를 시간에 따라 변하는 것으로 다룹니다.

RFC 7942는 Independent Stream 문서를 명시적으로 제외하므로 RFC 9947에 강제할 수 없습니다. 이 경계가 중요합니다. 교훈은 “이 BCP를 복제하라”가 아닙니다. 구현 증거에는 식별, 범위, 시간이 있으며, 그 속성들이 주장과 함께 이동할 때 공개 심의가 개선된다는 교훈입니다.

RFC 7841은 다른 경계를 보이게 합니다. Independent Stream Experimental RFC는 인터넷 표준 후보가 아닙니다. 강한 실험 증거가 새 작업을 촉발하거나 IETF 결정에 영향을 줄 수 있지만, 원래 발행물을 소급하여 IETF 합의로 바꾸지는 못합니다. 증거 반출 기록은 결과에 제도적 후광을 두지 말고 이 구별을 보존해야 합니다.

출처가 증명할 수 있는 것과 없는 것

인용된 출처는 RFC 9947의 지위, 프로토콜 필드, 제어 도메인 규칙, 실험 질문, 결과 공유 기대를 확립합니다. 관련된 프라이버시, 무결성, 한정 도메인, SRH 및 스트림 맥락도 확립합니다. 그러나 이 실험에 대한 결과 보고서, 배포된 운영자 인벤토리, 공개 데이터 세트를 제공하지는 않습니다.

여기서 결과가 늦었다는 주장은 하지 않습니다. RFC 9947은 2026년 3월에 발행되었고, 2년 문구는 기대일 뿐 만료된 마감이 아닙니다. 운영자가 보호된 자료를 공개해야 한다거나, 모든 유용한 평가가 공개 데이터에서 재현될 수 있다는 주장도 하지 않습니다.

결론은 더 좁습니다. 결과가 도착할 때 그 권한과 한계가 판독 가능해야 합니다. 도메인 경계는 실험 패킷과 원시 트래픽에는 닫혀 있는 채로, 신중하게 경계가 설정된 증거 객체가 그것을 통과할 수 있습니다. 그래야 기밀성과 공개 검토가 경쟁하는 구호가 아니라 양립 가능한 상태가 됩니다.

출처

  1. Lu Heng — The Policy Mirror
  2. Lu Heng — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Lu Heng — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. RFC Editor record for RFC 9947
  5. RFC 9947 — Application of the Alternate-Marking Method to the Segment Routing Header
  6. RFC 9341 — Alternate-Marking Method
  7. RFC 9342 — Clustered Alternate-Marking Method
  8. RFC 9343 — IPv6 Application of the Alternate-Marking Method
  9. RFC 8799 — Limited Domains and Internet Protocols
  10. RFC 8402 — Segment Routing Architecture
  11. RFC 8754 — IPv6 Segment Routing Header
  12. RFC 8986 — Segment Routing over IPv6 Network Programming
  13. RFC 7841 — RFC Streams, Headers, and Boilerplates
  14. RFC 7942 — Improving Awareness of Running Code