요약

  • PPPoE 엔드포인트를 PC에서 가정용 게이트웨이로 옮기면서, 평범한 1500바이트 LAN 패킷과 접속 캡슐화 사이에 익숙한 1492바이트 한계가 놓이게 되었습니다.
  • PPP-Max-Payload는 발견(discovery) 단계에서 더 큰 PPP 페이로드 지원을 광고했습니다. 세션에서 실제로 사용할 수 있는 크기는 로컬 인터페이스 한계와 일반적인 LCP 협상이 결정했습니다.
  • 큰 Echo 요청에 응답이 없다가 1492바이트 요청이 성공하면, 발신자는 해당 세션에서 1492 이하를 유지해야 할 수 있습니다. 이 비교는 개입된 모든 한계를 밝히지 않은 채 운영을 제약했습니다.

세션은 용량 증명서가 아니었다

접속 집중장치(access concentrator)는 발견되었고, 세션은 열렸으며, 심지어 양 끝점이 익숙한 PPPoE 상한을 넘는 수신 크기를 협상하기까지 했습니다. 그러나 그 어느 성과도 해당 크기의 패킷이 양 끝점 사이의 이더넷 구간을 실제로 통과할 수 있음을 보장하지 않았습니다.

바로 이 간극이 2006년 9월에 발표된RFC 4638의 특별한 관심사입니다. 그 주제는 단순히 더 큰 숫자가 아니었습니다. 이 문서는 양 끝점이 모두 이해할 수 있는 확장을 설명하고, 로컬 역량으로 한계를 두고, 그다음 앞선 합의가 제공하지 못한 운영상의 관찰로 다시 제한하는 과정을 다뤘습니다.

한 예시 시나리오가 이 구분을 구체적으로 보여줍니다. 발신자가 협상된 최대 크기의 LCP Echo 요청을 보내 응답을 받지 못하고, 이어 1492바이트 요청을 보내 응답을 받았다면, 명시된 비교 규칙에 따라 발신자는 해당 세션에서 1492를 넘어 보내서는 안 됩니다. 이는 프로토콜 시나리오이며, 기록된 장애 사례에 대한 주장이 아닙니다.

작은 성공이 유용한 이유는 정확히 큰 시도를 검증하지 않기 때문입니다. 또한 원인인 브리지, 인터페이스 또는 다른 조건을 지목하지도 않습니다. 작은 성공이 제공하는 것은 더 좁은 행동 근거입니다. 양 끝점이 사전에 합의했다는 이유만으로 이 세션에서 더 큰 크기를 계속 사용하지 말라는 것입니다.

비용은 이미 봉투 안에 있었다

원래의 산술은 1999년 2월의 PPP over Ethernet 명세인RFC 2516에 나옵니다. 1500옥텟의 이더넷 페이로드는 6옥텟 PPPoE 헤더와 2옥텟 PPP Protocol-ID를 담아야 했고, PPP 페이로드에는 1492옥텟만 남았습니다.

이 산정 경계가 중요합니다. 여기서 1500은 이더넷 페이로드이지, 이더넷 헤더·체크섬·프리앰블이나 추가 태깅을 포함한 전체 온와이어 프레임이 아닙니다. 전체 프레임 한계를 표시하는 장치는 다른 대상을 세고 있을 수 있습니다. 정의 없이 숫자만 비교하면 패킷이 보내지기도 전에 겉보기 불일치가 생깁니다.

RFC 4638은 두 오버헤드 중 어느 것도 제거하지 않았습니다. 1500옥텟 PPP 페이로드를 실어 보내려면 여전히 그 8옥텟을 위한 공간, 즉 명시된 6+2 산정 하에서 1508옥텟의 이더넷 페이로드가 필요했습니다. 이 제안은 baby-giant 또는 점보 프레임 지원으로 문서에서 설명되는, 더 큰 페이로드를 처리할 수 있는 이더넷 시스템에 의존했습니다.

이는 용량 요건이지 모든 구성에 적용되는 보편적 레시피가 아닙니다. 모든 인터페이스에 하나의 전체 프레임 설정을 지시하지도 않으며, 각 구현이 추가 태그를 어떻게 세는지도 정하지 않습니다. 하위 계층이 공간을 제공해야 했고, 새 발견 태그는 양 끝점의 의도를 명시적으로 만들 수 있을 뿐이었습니다.

한계보다 엔드포인트가 먼저 움직였다

RFC 4638은 문제를 광대역 아키텍처의 변화로 추적합니다. 문서가 기술한 구식 배치에서는 PC가 접속 장비를 통해 PPPoE를 시작했고, PC의 PPP 엔드포인트에 있는 1492바이트 한계는 보통 수용 가능했습니다.

가정용 게이트웨이는 이 인계 지점을 바꿔 놓았습니다. 게이트웨이는 LAN에서 평범한 IP over Ethernet을 종단하고, 광대역 접속 서버 쪽으로 PPPoE를 시작할 수 있었습니다. 그러면 LAN에서 나온 1500바이트 IP 패킷이 관례상 페이로드 한계가 1492인 PPP 세그먼트와 마주하게 됩니다. 패킷을 만드는 장비가 더 이상 그 제한된 세그먼트를 협상하는 장비가 아니었던 것입니다.

8바이트 자체는 커지지 않았습니다. 커진 것은 그 효과가 두 기대 사이의 경계로 옮겨 간다는 점이었습니다. 게이트웨이는 종단 호스트의 직접 참여가 이전에 더 명시적으로 만들어 주던 일을 떠안게 되었습니다.

문서는 PPPoA에서 PPPoE로의 전환도 논의하고, 1492바이트 설정을 지원하지 않는 배치된 PPPoA 고객 장비를 보고했습니다. 이는 2006년 기술에 대한 관찰이지, 당대의 장비 조사(센서스)도 아니고 모든 PPPoA 구현에 대한 주장도 아닙니다.

앞선 캡슐화도 무한하지 않았습니다. 1998년 7월에 발표된RFC 2364는 PPP over AAL5의 MRU를 해당 방향의 가상 연결 트래픽 계약에 있는 최대 CPCS-SDU로 한정했습니다. 마이그레이션은 하위 계층 계약을 바꿨을 뿐, PPP가 처음 만난 하위 계층 제약을 도입한 것은 아니었습니다.

더 많이 받는다는 것의 실제 의미

1994년 7월자RFC 1661의 Maximum-Receive-Unit은 Information 및 Padding 필드를 다루며, PPP Protocol 필드나 주변 프레이밍은 다루지 않습니다. 일반 PPP의 기본 MRU는 1500입니다. 그 일반 기본값이 PPPoE의 1492바이트 특정 제한을 지우지는 않습니다.

MRU는 수신 용량을 광고하거나 더 작은 패킷을 요청합니다. 피어가 그 용량까지 모든 패킷을 채우도록 강제하지는 않습니다. 따라서 제시된 상한, 협상된 한계, 관찰된 패킷 크기는 서로 모순 없이 달라질 수 있습니다.

이 확장은 PPPoE 발견 단계에 예비 선언을 도입했습니다. 발견 자체에도 고유한 역할이 있었습니다. PADI가 접속 집중장치를 탐색하고, PADO가 응답을 제시하며, PADR이 선택된 세션을 요청하고, PADS가 이를 확인합니다. 이더넷 주소와 세션 식별자가 이후 교환이 그 참여자와 연결되게 합니다.

이 시퀀스를 마쳤다고 모든 이후 PPP 단계가 끝나거나, 경로상의 모든 것을 인증하거나, 동작하는 IP 서비스가 확립되는 것은 아닙니다. 확장은 이 시퀀스를 LCP 이전에 하나의 추가 질문에 답하는 데 사용했습니다. 양 끝점이 1492를 넘는 페이로드 가능성을 이해하는가?

되돌아온 태그는 더 작은 답의 여지를 남겼다

더 큰 페이로드를 원하는 클라이언트는 PADI와 PADR 양쪽에 PPP-Max-Payload를 포함해야 합니다. 이를 수신한 지원 서버는 PADO와 PADS에서 클라이언트의 태그를 되돌려야 합니다. 태그의 type은 0x0120, 즉 10진수 288이며, 2옥텟 이진 값은 클라이언트가 양방향(송수신)에서 지원하는 최대 PPP 페이로드를 나타냅니다.

이 숫자들은 역할이 다릅니다. type은 옵션을 식별할 뿐, 288바이트의 페이로드 허용량이 아닙니다. 2옥텟 값은 발견 단계의 일부이며, 세션의 모든 패킷에 청구되는 반복 헤더가 아닙니다.

서버는 자체 최종 한계로 반드시 다시 쓰는 것이 아니라 클라이언트의 태그를 그대로 되돌립니다. 로컬 제약은 이후 계산에 들어갑니다. 절차는 1492를 최대값으로 시작하고, 태그가 존재하며 그 값을 초과하면 협상 가능한 최대값은 광고된 값과 인터페이스 MTU에서 8을 뺀 값 중 더 작은 쪽이 됩니다.

이어서 일반적인 LCP 협상이 실제 MRU를 결정합니다. 따라서 큰 발견 값은 그 크기를 쓰라는 명령이 아닙니다. RFC 4638은 다른 면에서 유효한 확장 역량 교환 내에서라도, 1500을 넘는 태그가 있어도 더 큰 MRU가 협상되지 않으면 일반 PPP의 1500 기본값이 유지된다고 명시합니다.

양측이 발견 단계에서 지원을 밝히지 않으면 1492 상한이 그대로 남습니다. 구형 장비는 모르는 태그를 무시할 수 있으며, 무시됨은 동의로 간주되어서는 안 됩니다. 1492 이하의 태그 역시 더 큰 허용량을 활성화하지 않습니다. 하위 호환성은 이해 부재와 새 조건의 수용을 구분하는 데 달려 있습니다.

중간의 장비들은 표를 던지지 않았다

발견과 LCP는 엔드포인트 사이에서 선언을 주고받았습니다. 중간 이더넷 장비는 양 끝점이 사용하려던 더 큰 프레임을 수용하지 않고도 그 작은 제어 메시지를 통과시킬 수 있었습니다. 어떤 중간 브리지도 협상에 서명하지 않았습니다.

그래서 RFC 4638은 세션이 열리고 1492를 넘는 크기가 협상된 후 발신자가 하나 이상의 MRU 크기 LCP Echo 요청을 보낼 수 있는 옵션을 가져야 한다고 규정합니다. 응답이 오지 않으면 발신자는 1492에서 반복할 수 있습니다. 그 작은 요청에 응답이 오면, 현재 세션에서 1492를 넘어 보내서는 안 됩니다.

이 요구들 사이의 구분은 의도된 것입니다. 역량은 기본적으로 활성화되고 구성 가능해야 하며, 네트워크에 대한 사전 지식은 비활성화를 정당화할 수 있습니다. 문서는 모든 세션에 동일한 필수 프로브, 재시도 횟수 또는 타이머를 지시하지 않습니다.

추론의 범위도 제한됩니다. 두 크기 모두에서 실패가 작은 쪽이 동작한다는 증명은 아니며, 작은 요청에 대한 응답이 큰 요청을 정당화하지도 않습니다. 단 한 번의 성공 교환은 양방향 최대 크기 전송의 영구 보장이 아닙니다.

RFC 1661은 LCP Echo 교환을 Opened 상태로 한정하고 대응하는 Identifier를 명시합니다. 모든 응답이 요청과 정확히 같은 크기여야 한다는 일괄 주장을 뒷받침하지 않습니다. 운영자에게 필요한 것은 “Echo 통과”라는 표시가 아니라 실제 송수신된 크기입니다.

접속 테스트는 인터넷 경로 탐색이 아니었다

라우팅된 경로 전반에서 패킷 크기 제약을 학습하는 별도의 역사가 있었습니다. 1990년 11월자RFC 1191은 Don't Fragment 비트와, 라우터가 단편화 없이 패킷을 전달할 수 없을 때의 ICMP 피드백을 사용하는 IPv4 경로 MTU 탐색을 기술했습니다.

그 상황에서 라우터는 패킷을 폐기하고 필요성을 보고하며, 발신지는 경로 추정을 줄입니다. 따라서 초과 크기의 IPv4 패킷이 항상 단편화되어 전달되는 것은 아닙니다. 전달 판단의 조건이 중요합니다.

PPPoE의 크기 비교는 자신의 세션과 중간 이더넷 처리를 다뤘습니다. 가입자와 원격 목적지 사이의 이후 인터넷 세그먼트 각각의 MTU를 확립할 수 없었습니다. 이 경계를 지키는 것이 테스트를 유용하게 만듭니다. 접속 질문에 답하면서, 다른 종류의 종단 간 질문을 해결한 것처럼 꾸미지 않는 것입니다.

레지스트리는 용량이 아니라 어휘를 제공했다

RFC 4638은 인터넷 표준이 아니라 Informational로 발표되었습니다. IESG 노트는 당시 표준 맥락에서 1500을 넘는 이더넷 페이로드에 주의를 당부했습니다. 이는 2006년 시점의 경고이며, 2026년의 표준 환경에 대한 진술이 아닙니다.

2007년 6월,RFC 4937은 PPPoE의 16비트 태그 타입 레지스트리에 대한 IANA 절차를 확립하고 PPP-Max-Payload를 10진수 288로 등록했습니다. 확보된IANA PPPoE 파라미터 레지스트리는 그 연관을 지금도 유지하고 있습니다.

등록은 독립 구현들이 같은 필드를 인식하게 합니다. 그러나 접속 네트워크의 프레임 용량을 인증하지도 않고, 보편적 채택의 시점을 표시하지도 않습니다. 1999년의 원래 캡슐화, 2006년의 확장, 2007년의 레지스트리 작업을 하나의 배치 사건으로 묶어서는 안 됩니다.

역사적 성과는 증거의 분업이었습니다. 발견은 공유 이해를 확립하고, LCP는 로컬 한계 안에서 협상하며, 운영상의 비교는 여전히 현재 세션을 제한할 수 있습니다. 양 끝점은 용량을 어떻게 사용할지 조율할 수 있었습니다. 그러나 실제 장비가 여전히 실어야 하는 그 8바이트를 협상으로 지워버릴 수는 없었습니다.