요약

  • RFC 3963은 모바일 라우터가 하나 이상의 모바일 네트워크 프리픽스를 이동시키되 그 뒤에 있는 노드들이 이동 사실을 알지 못하도록 하는 길을 열었습니다. R 플래그를 포함한 상태 0의 바인딩 확인 응답은 홈 에이전트의 처리와 프리픽스 포워딩을 확인할 뿐, 노드별 도달 가능성을 확인하는 것은 아니었습니다.
  • 명시적 프리픽스 옵션, 암묵적 사전 구성, 동적 라우팅은 서로 다른 근거 사슬을 만들어냈습니다. 따라서 내구성 있는 운영 기록은 바인딩 수락, 프리픽스 권한, 설치된 경로, 터널 상태, 노드 프로브, 세션, 전달된 서비스를 분리해서 다룹니다.

열차, 항공기 또는 차량 안에 있는 네트워크를 상상해 보십시오. 그 안의 카메라, 단말, 센서는 주소를 안정적으로 유지하며 하나의 게이트웨이를 계속 홈으로 취급합니다. 바깥 연결이 바뀐 사실을 학습하는 것은 게이트웨이, 즉 모바일 라우터뿐입니다. 2005년 1월 Standards Track으로 발표된RFC 3963이 제공한 경제성이 바로 이것이었습니다. 모든 모바일 네트워크 노드를 이동성 참여자로 만들지 않고 네트워크를 통째로 이동시키는 것입니다.

모바일 라우터는 외지에서 케어 오브 주소를 획득하고 홈 에이전트에 바인딩 업데이트를 보낸 뒤 R 플래그를 설정해 모바일 라우터 취급을 요청했습니다. 홈 에이전트는 라우터의 홈 주소를 새 케어 오브 주소에 바인딩했습니다. 그리고 권한이 부여된 모바일 네트워크 프리픽스로 향하는 패킷을 가로채 양방향 터널을 통해 모바일 라우터로 전달했습니다. 반환 트래픽은 같은 터널을 따라 돌아왔습니다. 내부 노드들에게는 이동이 보이지 않을 수 있었습니다.

이 압축이 강력했던 이유는 증명 범위가 좁았기 때문입니다. 상태 0과 R 플래그를 담은 긍정적 바인딩 확인 응답은 모바일 라우터가 업데이트가 처리되었고 자신의 프리픽스에 대한 포워딩이 설정되었다고 가정할 수 있게 해주었습니다. 그러나 이 응답은 다운스트림 기기를 열거하거나, 소켓을 열거나, 세션을 보존하거나, 애플리케이션을 테스트하지 않았습니다. 홈 주소, 케어 오브 주소, 프리픽스 집합, 포워딩 상태에 대한 제어 평면 영수증이었습니다.

R 플래그는 요청이지 신원이 아니었다

모바일 라우터는 바인딩 업데이트에 R을 설정합니다. 요청을 수락한 홈 에이전트는 긍정적 확인 응답에 R을 설정하며, 대응 노드(Correspondent Node)는 그 취급을 부여하지 않는 것이 원칙이었습니다. 이 비트는 수신 측 홈 에이전트가 이동성 바인딩을 처리하는 방식을 바꾸지만, 비트 자체가 발신자를 인증하지는 않습니다. RFC 3963은 모바일 라우터와 홈 에이전트 간 시그널링이 IPsec으로 인증되도록 요구했습니다. 보호된 연관(association)이 진위성을 제공했고, 플래그는 그 연관 안에서 의미를 부여했습니다.

이 구분이 중요한 이유는 운영 대시보드가 프로토콜 비트를 더 넓은 주장으로 확장하는 경우가 많기 때문입니다.R=1은 "이것이 의심할 여지 없는 라우터다"를 의미할 수 없으며,status=0이 "네트워크가 건강하다"를 의미할 수 없는 것과 마찬가지입니다. 유용한 영수증은 바인딩 업데이트 시퀀스 번호와 수명, H 및 R 플래그, 정확한 터널 엔드포인트, IPsec 연관, 그 결과 만들어진 확인 응답, 그로 인해 설치된 경로 객체를 함께 보존합니다.

이 문서가 이동성 문서군에서 차지하는 위치가 범위를 확정해 줍니다.RFC 3775는 당대의 모바일 IPv6 호스트 기반 장치를 제공했고,RFC 6275가 이후 그 기반을 개정했습니다. RFC 3963은 모바일 엔드포인트 뒤에 네트워크를 추가했습니다. 하나의 제어 교환을 그 네트워크 내부 모든 것에 대한 관찰로 바꾸지는 않았습니다.

어떤 프리픽스가 속했는지 알아내는 세 가지 방법

명시적 모드에서는 바인딩 업데이트가 하나 이상의 모바일 네트워크 프리픽스 옵션을 담았습니다. 홈 에이전트는 그 주장을, 모바일 라우터가 사용하도록 권한을 받은 프리픽스를 기록하는 프리픽스 테이블과 대조할 수 있었습니다. 이는 최선형 조립이 아니었습니다. 홈 에이전트가 나열된 모든 프리픽스에 대해 포워딩을 설정할 수 없다면, 어떤 것도 포워딩하지 않고 상태 141로 업데이트를 거부해야 했습니다. 라우터가 사용 권한이 없는 프리픽스는 상태 142를 낳았습니다.

이 전부 아니면 전무(all-or-nothing) 규칙 덕분에 확인 응답이 이해 가능하게 유지되었습니다. 그렇지 않으면 하나의 상태 코드가 부분적으로 이동된 네트워크를 숨길 수 있었습니다. 그러나 프리픽스 테이블 일치는 여전히 권한 부여 사실이었지, 그 프리픽스 안 주소를 쓰는 센서나 서버가 살아 있다는 증거는 아니었습니다.

암묵적 모드는 근거의 위치를 뒤집었습니다. 바인딩 업데이트는 모바일 네트워크 프리픽스 옵션을 생략하고, 홈 에이전트는 메시지 밖에 구성된 정보로부터 프리픽스 집합을 얻었습니다. 그런 정보가 없다면 상태 143으로 업데이트를 거부했습니다. 같은 긍정적 확인 응답이 현재 요청에 담긴 바이트에 근거할 수도, 다른 곳에 운영자가 유지하는 기록에 근거할 수도 있었던 것입니다. 제대로 된 감사는 어느 모드가 사용되었는지, 그리고 외부 데이터의 버전과 소유자를 기록합니다.

터널 위 동적 라우팅은 세 번째 길을 제공했습니다. 프리픽스 관점을 적응시킬 수 있었지만, 보호하고 관찰해야 할 대상도 바꿉니다. RFC 3963은 라우팅 교환이 내부 토폴로지를 드러낼 수 있다고 경고하며 ESP 기밀성을 권고했습니다. 그러므로 "홈 에이전트에 경로가 있다"는 결코 완전한 출처(provenance) 진술이 아니었습니다. 그 경로는 정적일 수도, 명시적으로 요청된 것일 수도, 암묵적으로 구성된 것일 수도, 라우팅 프로토콜로 학습된 것일 수도 있기 때문입니다.

가장 날카로운 경고는 정적 경로 논의에 있었습니다. 정적 경로는 시그널링을 줄여 주지만, 연관된 모바일 라우터가 도달 불가능한 상태에서도 설치된 채로 남을 수 있었습니다. 경로 테이블은 의도된 포워딩을 진실하게 서술하면서도 현재의 생존 여부에 대해서는 거짓을 말할 수 있었습니다. 이 문장은 RFC를 이동성 설계에서 근거적 교훈으로 바꿉니다.

터널은 편의와 실패를 한곳에 모았다

기본 지원(basic support)에서는 모바일 네트워크 노드와 대응 노드 사이의 트래픽이 홈 에이전트를 통과했습니다. 다운스트림 방향으로 홈 에이전트는 케어 오브 주소로 패킷을 캡슐화했습니다. 모바일 라우터는 터널 모드 IPsec이 이미 그 보호를 제공하지 않는 한 외부 출발지를 홈 에이전트로 확인했고, 내부 목적지가 모바일 네트워크 프리픽스에 속하는지 확인한 뒤 내부로 포워딩했습니다.

업스트림 확인은 책임이 나뉘었습니다. 모바일 라우터는 자신의 모바일 네트워크 프리픽스 밖의 내부 출발지를 거부하는 것으로 기대되었고, 홈 에이전트는 터널 트래픽을 내보내기 전 자체 토폴로지 확인을 수행했습니다. 이 통제들은 주소 오용을 제한했습니다. 애플리케이션 사용자를 인증하거나, 기기를 증명하거나, 최종 서비스가 완료되었음을 증명하지는 않았습니다.

기본 지원은 모바일 네트워크 프리픽스 트래픽에 대한 경로 최적화도 정의하지 않았습니다. 홈 에이전트 경로는 직접 경로보다 길 수 있었고, 모바일 라우터들이 트리를 이루면 중첩으로 터널이 곱해질 수 있었습니다.RFC 4885,RFC 4886,RFC 4887은 용어, 목표, 네트워크 이동성 문제 공간을 문서화했습니다.RFC 4888은 경로 최적화 문제를 분석했고RFC 4889는 해법 공간을 지도화했습니다. 이 문서들의 존재 자체가 "포워딩이 설치됨"과 "경로가 최적화됨"이 별개의 이정표였음을 상기시킵니다.

이후 문서들은 인접 부분을 바꾸면서도 그 경계를 지우지 않았습니다.RFC 5488은 NEMO를 위한 DHCPv6 프리픽스 위임 모델을 규정했고,RFC 6276은 모바일 네트워크를 위한 또 다른 DHCPv6 프리픽스 위임 메커니즘을 제공했으며,RFC 6089는 모바일 IPv6와 NEMO를 위한 플로우 바인딩을 서술했습니다. 각각은 추가적인 근거 및 정책 표면을 만듭니다. 어느 것도 바인딩 확인 응답을 노드별 프로브로 만들지 않습니다.

유지 관리되는 기록도 중요합니다.RFC Editor 정보 페이지,RFC 3963 정오표 검색,IETF Datatracker 기록,IANA Mobility Parameters 레지스트리는 발행 상태, 보고된 정정 사항, 할당된 프로토콜 값을 확정합니다. 레지스트리 할당은 조정을 확립합니다. 특정 사이트에서의 채택이나 올바른 동작을 확립하지는 않습니다.

따라서 운영 장부는 의도적으로 복수형이어야 합니다. 이동 감지, 홈 주소와 케어 오브 주소, 바인딩 업데이트의 시퀀스·수명·플래그·프리픽스 옵션, 명시적·암묵적·라우팅 모드, 프리픽스 근거와 권한 결과, 전부 아니면 전무 결정, 확인 응답 상태와 R 플래그, IPsec과 터널 엔드포인트, 설치되거나 제거된 모든 경로, 외부·내부 주소 확인, 프리픽스별 프로브, 그리고 노드·세션·서비스별 독립 관찰을 보존하십시오. 그러자 이 사슬은 성공이 얼마나 멀리 도달했는지를 정확히 말할 수 있습니다.

RFC 3963은 이동해야 할 것을 좁혀 네트워크를 이동시켰습니다. 그 지속적 규율은 정반대입니다. 하나의 성공한 신호가 증명할 수 있는 범위를 절대 넓히지 말 것.

출처