요약

  • 평범한 ICMP 인용은 IP 데이터그램은 보존하면서도 포워딩을 결정했던 MPLS 스택을 잃을 수 있었다. RFC 4950은 오류를 생성하는 라우터에 도착한 시점의 스택을 추가했다.
  • 이 추가는 IP 인용을 유지하면서 별도로 프레이밍된 객체를 사용했다. 등록된 형식은 로컬 의미의 레이블 값을 전역 신원으로 바꾸지 않았다.
  • 오류에 더 많은 세부 정보가 담긴다고 해서 더 많은 홉이 보이는 것은 아니다. 레거시 파싱, TTL 처리, 오류의 복귀 경로, 선택적 공개는 여전히 별개의 제약이었다.

증거는 인용 범위 밖에 있었다

RFC 4950의 시작 부분에는 시사적인 순서가 나온다. 레이블 스위칭 라우터가 자신이 전달할 수 없는 MPLS 캡슐화 데이터그램을 받는다. 라우터는 레이블 스택 전체를 벗겨 IP 데이터그램을 노출시키고, 그 데이터그램을 오류 처리에 넘긴다.

이어지는 ICMP 메시지는 전달이 실패한 이유를 밝힐 수 있다. 원본 IP 헤더와 페이로드의 앞부분 바이트도 담을 수 있다. 그러나 패킷이 라우터에 들어왔을 때 그것을 감싸고 있던 스택에 대한 기술은 없다.

이 생략이 중요한 이유는, 그 스택이야말로 라우터가 패킷을 포워딩하기 위해 참조했을 대상이기 때문이다. 인용은 정확하면서도 관련 포워딩 맥락을 놓칠 수 있다. 반드시 훼손된 기록은 아니었다. 이 특정 진단 질문에 대해서는 잘못된 경계를 그어 만든 기록이었다.

2007년 8월에 공표된RFC 4950은 그 빠진 맥락을 위한 확장 객체를 제공했다. 선택된 오류 메시지는 수신 시점의 MPLS 스택을 담아야 한다. 동시에 원본 IP 헤더와 앞부분 페이로드도 여전히 담아야 한다. 새 증거는 인용을 보충할 뿐, 그것을 대체하지 않는다.

중요한 변화는 단순히 오류가 길어질 수 있게 된 것이 아니었다. IP 오류 처리로 넘어가는 과정에서 그렇지 않으면 버려졌을 무언가를 보고서가 보존할 수 있게 된 것이다.

원래는 대화를 찾기 위한 인용이었다

그 이전의 목적은 1981년 9월에 공표된RFC 792에서 확인된다. Time Exceeded 형식은 인터넷 헤더와 원본 데이터그램 데이터의 첫 64비트를 담았다. 이 여덟 데이터 바이트는 수신 호스트가 오류를 적절한 프로세스와 연관 짓는 데 도움을 주었다. 상위 프로토콜이 포트를 사용한다면 그 번호들이 앞부분 근처에 있을 것이라고 명세는 기대했다.

이는 실패를 그것을 유발한 통신과 연결하는 방법이었다. 중간 시스템이 사용한 모든 상태를 재현하겠다는 약속이 아니었다. 또한 이 역사적 형식을, 이후 모든 ICMP 메시지가 항상 정확히 8바이트의 페이로드를 인용했다는 주장으로 오해해서는 안 된다.

MPLS는 인용된 계층과 포워딩 계층 사이의 특히 선명한 불일치를 가져왔다. MPLS 스택은 네트워크 계층 헤더 앞, 데이터 링크 헤더 뒤에 놓인다. 인용을 IP 페이로드 쪽으로 더 확장해도 이미 벗겨진 스택을 자동으로 회복하지는 못한다.

2001년 1월의RFC 3032는 각 레이블 스택 엔트리를 4옥텟으로 기술한다. 최상위 엔트리가 먼저 온다. S 비트는 바닥 엔트리를 식별한다. 최상위 레이블을 조회하면 다음 홉과 스택 연산을 얻는다: 레이블 교체, 엔트리 팝, 또는 최상위 교체와 추가 엔트리 푸시.

이들은 잘 갖춰진 IP 기술에 붙는 장식적 주석이 아니다. 라우터가 다음에 무엇을 할지 결정하는 상태 그 자체일 수 있다.

도착은 특정 순간이다

RFC 4950의 객체는 좁은 시점적 주장을 한다. 하나의 인스턴스는 오류를 생성하는 라우터에 도착한 형식과 순서 그대로의 MPLS 스택 전체를 나타낸다.

성공적으로 처리된 이후의 출력 스택을 보여주겠다는 주장이 아니다. 누군가 나중에 보고서를 읽는 시점의 라우터 구성 덤프도 아니다. 다른 패킷에 어떤 레이블이 적용되었을지 말해주지도 않는다.

이 객체는 Time Exceeded와 Destination Unreachable 메시지에, ICMPv4와 ICMPv6 모두에 대해 부착될 수 있다. 모든 ICMP 메시지 유형에 붙이라는 일반적 초대가 아니다.

객체 헤더는 Class-Num 1, C-Type 1을 사용한다. 객체 길이는 헤더 4옥텟에 스택 엔트리 하나당 4옥텟을 더한 값이다. 따라서 엔트리 셋은 16옥텟 객체를 만든다. 이는 패킷 캡처가 아니라 구성된 크기 예시다. 객체 앞의 별도 확장 헤더는 그 16옥텟에 포함되지 않는다.

각 엔트리는 20비트 레이블, 당시 EXP라 불린 3비트, S 비트 1개, TTL 8비트를 담는다. 2009년 2월,RFC 5462는 EXP를 Traffic Class, 즉 TC로 이름을 바꾸고 의도된 사용법을 명확히 했다. 이 변경으로 스택 엔트리가 커지지는 않았다.

따라서 역사적 표시 화면이 옛 필드 이름을 쓴다고 해서, 현대 운영자에게 그 비트를 제한 없는 실험 공간으로 다루는 허가가 주어지는 것은 아니다. 도구가 출력하는 숫자만큼이나 형식의 날짜와 의미가 중요하다.

공유된 객체 유형이 곧 공유된 레이블 신원은 아니다

공통 객체 클래스는 서로 다르게 작성된 리더가 보고서의 구조에 대해 합의하게 만든다. 그 구조 안의 모든 숫자를 전역적으로 의미 있게 만들지는 않는다.

RFC 3031은 MPLS 레이블을 포워딩 등가 클래스의 로컬 의미 식별자로 정의한다. 네트워크 계층 목적지 주소의 인코딩이 아니다. 그 의미는 적용되는 바인딩과 레이블 공간이 결정한다.

두 라우터가 같은 값을 출력한다고 해서, 그것만으로 두 라우터를 가로지르는 하나의 영속적 객체가 존재한다는 결론이 되지는 않는다. 패킷이 포워딩 맥락을 옮겨 가면서 경로는 다른 값을 사용할 수 있다. 반복되는 값은 서로 다른 맥락에 속할 수 있다.

이 구분은 깔끔한 traceroute 표시에서 재구성할 수 있는 것의 한계를 정한다. 숫자들의 나열은 지도로 잇기 쉬워 보인다. 그러나 그 해석에는 산술적 등식만이 아니라 보고 위치와 관련 로컬 상태가 필요하다.

RFC 4950에 기록된 IANA의 확장 클래스와 서브타입 할당은 보고서의 어휘를 조율한다. 보고서가 기술하는 개별 레이블을 할당하지는 않는다. 증거를 운반하는 방식을 표준화하는 것은 그 증거가 나오는 네트워크를 지배하는 것보다 작은 일이다.

경계는 기존 소프트웨어 위에서 살아남아야 했다

스택 객체는 네 달 전에 공표된RFC 4884에 의존했다. 그 문서는 선택된 ICMP 메시지를 위한 다중 파트 구조를 정의했다: 원본 데이터그램 인용, 확장 헤더, 하나 이상의 확장 객체.

리더는 인용이 어디서 끝나는지 알아야 한다. RFC 4884는 이전에 예약된 공간을 사용하는 8비트 길이 속성을 제공했다. ICMPv4의 단위는 32비트 워드, ICMPv6은 64비트 워드다. 확장이 있으면 인용된 영역은 최소 128옥텟을 담아야 하고, 원본이 더 짧으면 0으로 패딩하며 적절한 경계에 정렬해야 한다.

그 최소값은 또 하나의 호환 장치였다. 문서는 자신의 공표 전까지, 즉 1999년부터 공표 시점 사이에 만들어진 구현들이 새 길이 속성을 지정하지 않은 채 정확히 128 인용 옥텟 뒤에 확장을 두어 왔다고 기술한다.

일부 리더는 그 결과 고정된 위치를 본다. 명시된 길이를 따르지 않는다. 새 송신자가 더 긴 인용을 담을 수 있어도, 확장을 인식하는 구식 리더는 여전히 확장이 시작될 것으로 기대하는 곳을 본다.

이런 리더와 호환하려는 송신자에게 실용적 선택은 정확히 128옥텟이었다. 그 요구가 없는 송신자는 메시지 크기 한도 내에서 더 담을 수 있었다. 개정 형식에서 최소값이었던 것이 배포된 소프트웨어에는 고정 경계로 남았다.

이는 공짜 하위 호환이 아니었다. 확장을 모르던 고전적 응용은 추가된 바이트를 인용된 원본의 일부로 취급할 수 있었다. RFC 4884는 알려진 결과를 검토했을 뿐, 모든 구형 응용이 영향을 받지 않으리라고 약속하지는 않았다.

기본 해석과 과거 호환 조치

길이 속성이 0인 메시지를 받은 규격 준수 응용은 통상 확장이 없다고 판정해야 한다. 이 규칙은 명확하지만, 속성을 아예 설정하지 않던 구형 구현이 내보낸 확장은 놓친다.

그래서 RFC 4884는 규격 준수 traceroute 구현에 구형 동작을 위한 비기본 모드를 제공하도록 요구했다. 길이 없이 충분히 긴 메시지가 주어지면, 그 모드는 128옥텟 인용 뒤의 고정 위치를 살펴 유효한 확장 버전과 체크섬을 찾을 수 있다.

이 예외는 명시적이었다. 리더가 모든 평범한 해석을 선언되지 않은 추측에 의존하게 할 필요는 없었다. 운영자는 특정 과거 관행을 인식하기 위한 모드를 선택할 수 있었다.

확장 헤더는 버전 2를 사용한다. 체크섬은 구조적 점검이지 암호학적 자격 증명이 아니며, 모두 0인 체크섬 값은 전송되지 않았음을 뜻한다. 객체 길이는 자신의 헤더와 페이로드를 포함해 옥텟 단위로 측정된다. 인식 불가 객체가 있다고 해서 그 자체로 ICMP 메시지가 기형이 되는 것은 아니다.

이 유연성에도 신중한 파싱이 필요하다. 잘못된 길이 속성은 표시를 불편하게 하는 것을 넘어 안전하지 않은 읽기를 만들 수 있다. 수신자는 자신이 이해하는 객체에 대한 정책과 함께 구문 검사가 필요하다.

스택을 해독할 수 있다고 해서 진짜 보고자가 누구인지 확립되지는 않는다. 형식 유효성, 프로브와의 연관, 보고 출처의 인증은 서로 다른 질문으로 남는다.

서로 다른 역할을 하는 두 개의 스택

레이블이 ICMP 오류에 관여하는 또 다른 방식이 있다. RFC 3032가 MPLS 도메인을 통한 오류 복귀를 기술하면서 나온다.

내부 라우터는 원본 IP 출발지로 직접 라우팅하는 방법을 모를 수 있다. 기술된 한 방법은 생성된 ICMP 메시지를 레이블 스위치드 봉투에 넣어 일단 원본 목적지 쪽으로 보내는 것이다. 그러면 결국 출발지로 되돌아가는 경로를 아는 라우터에 도달할 수 있다.

레이블 값은 복사될 수 있고, TTL은 새 메시지의 여정에 맞게 설정된다. 이 레이블들은 오류 보고서를 둘러싼 활성 포워딩 상태다. 보고서 안에 담긴, 원본 패킷의 도착 시점 상태를 기록하는 RFC 4950 객체가 아니다.

값이 비슷해 보이더라도 이 구분은 중요하다. 보고서는 한 패킷의 수신 스택을 보존하면서, 또 다른 스택이 우회하는 복귀 경로로 보고서를 운반할 수 있다.

표시된 왕복 시간에는 그 복귀가 포함된다. 수신 스택 객체를 추가한다고 해서 관측자가 측정된 지연 전부를 특정 전방 링크에 배분할 수 있게 되는 것은 아니다. 증거를 풍부하게 하지만 측정의 비대칭을 없애지는 않는다.

내용이 늘어난다고 응답이 늘어나는 것은 아니다

RFC 4950은 ICMP와 MPLS의 일반적 관계 또는 캡슐화별 TTL 처리를 재정의하지 않음을 명시적으로 밝힌다. 그 처리가 평범한 traceroute를 무력화한다면 강화된 형식도 무력화된다.

2003년 1월에 공표된RFC 3443은 관련된 TTL 모델들을 구분한다. Uniform 처리는 터널 입출구에서 내부와 외부 TTL을 동기화한다. Pipe와 Short Pipe 모델은 내부 값과 무관한 외부 시작 값을 사용할 수 있다.

따라서 내부 프로브는 레이블 스위치드 경로를 지나는 동안, 송신자가 기대하는 홉별 Time Exceeded 응답을 불러내지 못할 수 있다. 이는 외부 TTL이 무제한이거나 모든 ICMP 오류가 금지된다는 뜻이 아니다. 응답 형식이 개선되었다고 해서 측정의 트리거가 보장되는 것은 아니라는 뜻이다.

공개는 또 하나의 독립적 선택이다. RFC 4950은 ICMP 메시지의 목적지—예컨대 관리 주소 블록—에 따라, 또는 전역 설정이나 수신 스택의 깊이에 따라 스택을 담는 방식을 논의한다.

레이블 행을 받지 못한 관측자는 그 부재만으로는 원인을 분리할 수 없다. 정보가 내보내지지 않았거나, 전달되지 않았거나, 공개되지 않았거나, 인식되지 않았을 수 있다. 객체의 부재는 MPLS의 부재에 대한 충분한 증거가 아니다.

문서는 2007년에 그 메커니즘이 이미 널리 배포되어 있다고 말했다. 이는 명세 안의 역사적 서술이지, 현재의 조사 결과도 공표 당일 모든 네트워크가 채택했다는 증거도 아니다.

이득은 실재하면서도 한정되어 있었다. 보고서는 한때 인용 범위 밖에 있던 포워딩 맥락을 보존할 수 있었다. 그러나 한 관측자의 부분적 시야를 네트워크의 완전한 기술로 바꾸지는 못했다.