요약

  • RFC 2023은 IPv6를 두 개의 관문 뒤에 두었습니다. PPP가 먼저 네트워크 계층 프로토콜(Network-Layer Protocol) 단계에 도달해야 했고, 이어서 IPv6CP가Opened상태에 도달해야 했습니다. 제어 패킷은0x8057을, 통과가 허용된 IPv6 데이터그램은0x0057을 사용했습니다.
  • 인터페이스 토큰(Interface-Token) 협상은 그 지점 간(point-to-point) 링크에서 두 32비트 값을 서로 다르게 만들었습니다. 이는 어느 한쪽 피어도 인증하지 않았고, 전역 고유성, 주소 소유권, 사용 가능한 경로, 패킷 수신 또는 애플리케이션 성공을 입증하지도 않았습니다.

PPP를 통해 IPv6를 전달하는 최초의 표준 트랙 사양에는 드러내볼 만한 특이점이 있습니다. 한 엔드포인트가 0인 Interface-Token을 요청할 수 있었습니다. RFC 2023에서 피어는 0이 아닌 제안 값으로 답했고, 그 응답은 문서가 Configure-Ack이라 부르는 형식이었습니다. 2년 뒤 RFC 2472는 이 응답을 Configure-Nak로 변경하여, 정확한 수용과 대체 값 제안 사이의 통상적인 구분을 회복했습니다.

이 수정이 중요한 이유는 PPP 응답의 이름이 단순한 형식적 절차가 아니기 때문입니다. 이름은 어떤 증거가 만들어졌는지를 서술합니다. Ack는 통상적으로 최신 요청이 수용되었다고 말합니다. Nak는 요청이 그대로는 받아들일 수 없지만 대신 가능할 수 있는 값을 제공한다고 말합니다. Reject는 어떤 옵션을 협상 대상에서 제거합니다. RFC 2023의 토큰 메커니즘은 이 세 경로를 모두 사용해 하나의 좁은 문제를 해결했습니다. 하나의 PPP 링크 양 끝이 같은 32비트 토큰으로 끝나서는 안 된다는 것입니다.

그것이 해결한 전부였습니다.

네트워크 프로토콜은 링크 프로토콜 뒤에서 기다렸다

PPP는 동작하는 캐리어를 모든 종류의 패킷을 보낼 수 있는 허가로 취급하지 않았습니다. RFC 1661은 작업을 계층과 단계로 나누었습니다. LCP는 데이터 링크 연결을 수립하고 구성하고 시험했습니다. 선택적 인증이 뒤따를 수 있었습니다. 그 후에야 PPP는 네트워크 계층 프로토콜 단계에 들어갔으며, 이 단계에서 별도의 네트워크 제어 프로토콜(NCP)이 각 네트워크 계층 프로토콜을 구성했습니다.

RFC 2023은 IPv6CP를 통해 이 구조에 IPv6를 넣었습니다. 제어 교환에는 자체 PPP 프로토콜 값, 16진수8057이 있었습니다. IPv6 데이터는 다른 값인0057을 사용했습니다. 이 구분 덕분에 인과 순서가 회선상에서 드러났습니다. 제어 프로토콜이 조건을 협상했고, 데이터 프로토콜은 그 결과인 허가를 사용했습니다.

따라서 IPv6가 통신되기 전에 두 관문이 열려야 했습니다. PPP가 네트워크 계층 프로토콜 단계에 도달해야 했고, IPv6CP가Opened에 도달해야 했습니다. 너무 일찍 도착한 IPv6CP 패킷은 조용히 폐기되어야 했습니다. 일반 PPP 규칙에 따라, 대응하는 NCP가 열려 있지 않은 상태에서 도착한 지원되는 네트워크 계층 패킷 역시 폐기되었습니다.

이 관문들은 흔한 해석 오류를 막습니다. LCPOpened는 “IPv6 준비 완료”를 의미하지 않았습니다. 데이터 링크 구성 교환이 완료되었다는 것만을 의미했습니다. 네트워크 단계는 IPv6CP가 협상할 수 있도록 허용했지만 그 협상을 완성하지 않았습니다. IPv6CPOpened는 IPv6 패킷을 통과시켰지만 경로를 만들거나 데이터그램을 전송하지 않았습니다.

두 개의 잠정 값이 마주치다

RFC 2023의 Interface-Token 옵션은 유형 1(Type 1), 길이 6(Length 6)이었습니다. 1옥텟 유형, 1옥텟 길이, 그리고 32비트 토큰입니다. 각 구현은 자신의 쪽에 대해 잠정 값을 선택했습니다. RFC는 유사한 기기 사이에서조차 달라질 가능성이 높은 여러 출처에서 뽑은 0이 아닌 값을 선호했습니다. 링크 계층 주소만으로는 항상 충분하지 않다고 명시했습니다. 좋은 출처가 없다면 엔드포인트는 0을 요청하고 피어에게 도움을 청할 수 있었습니다.

수신자는 피어의 Configure-Request에 들어 있던 토큰을 자신이 가장 최근에 보낸 Configure-Request의 토큰과 비교했습니다. 서로 다른 0이 아닌 값이라면 간단한 경우였습니다. 원격 토큰이 승인(acknowledge)되었습니다. 같은 0이 아닌 값이라면 충돌이 드러났습니다. 수신자는 다른 0이 아닌 제안 값을 담은 Configure-Nak를 보냈습니다. 둘 다 0이면 Configure-Reject를 통해 자동 협상이 끝났습니다. 기본 토큰을 가정할 수 없었고, 복구 절차는 규정되지 않았습니다.

교차 Nak(crossed-Nak) 사례가 가장 미묘합니다. 각 쪽이 서로에게 같은 대체 값을 제안할 수 있습니다. Nak에서 받은 토큰이 자신이 피어에게 마지막으로 제안한 값과 다르다면, 그 값을 새 Configure-Request에 넣을 수 있었습니다. 값이 같다면 다른 잠정 토큰을 다시 선택해야 했습니다. 이 순서는 반복될 수 있었지만, 문서는 독립적인 선택이 빠르게 갈라질 것으로 기대했습니다.

이것은 레지스트리 없이 이루어지는 수렴입니다. 피어들은 전역 기관에 자문하지 않습니다. 서로의 로컬 제안을 비교하고, 충돌을 드러내고, 다시 시도합니다. 결과는 그 결과를 낳은 비교에 따라 범위가 한정됩니다. 이 링크의 양 끝에서, 이 협상 안에서 값이 달라진다는 것입니다.

Ack, Nak, Reject는 서로 다른 접수증을 만든다

0이 아닌 요청 토큰에 대한 Configure-Ack은 하나의 단방향 교환에서 그 옵션의 수용을 기록합니다. 반대 방향이 완료되었다고 말하지 않습니다. 피어가 자칭하는 존재가 맞는지도 말하지 않습니다. RFC 2023은 보안을 다루지 않았고, Interface-Token은 인증 프로토콜이 아니었습니다.

Configure-Nak는 더 좁은 사실을 기록합니다. 현재 요청이 수신자가 수렴할 의사가 있는 값이 아니며, 다른 값이 제안되었다는 것입니다. 요청자가 수정된 패킷을 보냈다거나, 새 토큰이 승인되었거나, IPv6CP가 이후 열렸다는 증거가 아닙니다.

Configure-Reject는 이 옵션의 협상 경로가 끝났음을 기록합니다. 수신자가 그 옵션을 구현하지 않았음을 의미할 수도 있고, RFC 2023이 서술한 0 대 0 실패를 표현한 것일 수도 있습니다. 유효한 거절 이후의 다음 Configure-Request는 Interface-Token을 생략해야 합니다. 따라서 거절은 대체 토큰이 존재한다는 증거로 읽을 수 없습니다.

0 값 사례는 RFC 2472의 이후 수정이 단순한 문구 교정 이상이었던 이유를 보여줍니다. RFC 2023은 0 요청에 대한 0이 아닌 제안을 담은 Ack를 서술했습니다. RFC 2472는 그 응답을 Nak로 바꿨습니다. 이후 문서는 접수증을 사건에 맞췄습니다. 피어가 요청을 그대로 수용한 것이 아니라 대체 값을 제안하고 있었다는 것입니다. 또한 32비트 토큰을 64비트 Interface-Identifier로 교체했습니다. RFC 5072가 이후 RFC 2472를 대체했고, 오늘날 IANA 레지스트리는 IPv6CP에 대해 RFC 5072를 인용합니다. 따라서 RFC 2023은 현재의 구성 지침이 아니라 역사적 설계 단계로 읽어야 합니다.

압축 역시 단방향 약속이었다

IPv6CP는 유형 2(Type 2)의 IPv6-Compression-Protocol 옵션도 담았습니다. 이는 지정된 IPv6 압축 프로토콜을 사용하는 패킷을 수신할 수 있는 능력을 신호했습니다. 양방향 압축을 위해서는 각 쪽이 옵션을 따로 요청해야 했고, 기본값은 압축 없음이었습니다.

이 옵션은 같은 증거 규율을 강화합니다. 수용된 수신 능력은 압축된 패킷이 아닙니다. 압축된 패킷은 성공한 압축 해제가 아닙니다. 성공한 압축 해제는 경로 도달 가능성이나 애플리케이션 전달이 아닙니다. 이 메커니즘이 이 글에 등장하는 이유는 단 하나입니다. IPv6CP의Opened상태가 여러 협상된 조건을 요약할 수 있었음을 보여주기 때문입니다. 압축 알고리즘과 그 자체의 상태 이력은 별개의 주제로 남습니다.

로컬 고유성은 전역 신원이 아니었다

RFC 2023은 토큰이 PPP 링크 내에서 고유해야 한다고 말했습니다. 이 표현은 보장과 그 경계를 동시에 제공합니다. 최종 값들은 하나의 지점 간 링크 양 끝을 구별합니다. 전역 네임스페이스에서의 할당이 아닙니다. 무작위 시드는 갈라질 확률을 높일 뿐, 증명서를 발행하지 않습니다.

서로 다른 토큰 쌍은 어느 엔드포인트 뒤의 사람, 조직, 기기 또는 계정을 식별하지 않습니다. 어느 쪽이 그 링크를 사용할 권한이 있었는지도 보여주지 않습니다. 토큰으로 형성된 IPv6 주소의 소유권도 확립하지 않습니다. 피어 너머에 경로가 존재하는지, 정책이 전달을 허용하는지, 원격 프로토콜 스택이 아직 살아 있는지를 증명하지도 않습니다.

관찰된0057PPP 프레임조차 그 관찰 지점에서 한 프레임이 하나의 IPv6 패킷을 실은 것으로 분류되었다는 사실만을 증명합니다. 전달을 증명하려면 관찰자는 이후의 증거가 필요합니다. 의도된 엔드포인트에서의 수신, 무결성 검사, 전송 또는 애플리케이션 승인, 그리고 이 사건들을 결합할 만큼 충분히 강한 상관관계입니다. 어떤 상태 머신 레이블도 이 빠진 접수증들을 조용히 대신해 주지 않습니다.

따라서 RFC 2023의 지속적인 교훈은 32비트가 충분했다는 것이 아닙니다. 그것들은 곧 교체되었습니다. 교훈은 분산 프로토콜이 불일치를 가시화하고 한 라운드를 더 요구함으로써, 빈틈없이 경계가 정해진 조정 문제를 해결할 수 있다는 것입니다. 토큰은 갈라졌습니다. 링크는 로컬 주소 구분을 갖게 되었습니다. 그보다 큰 모든 것—신원, 권한, 소유권, 도달 가능성, 결과—은 여전히 자신만의 증명을 필요로 했습니다.

출처