요약

  • RFC 7157은 IPv4 NAPT가 종종 하나로 묶어버리던 세 가지 선택, 즉 소스 주소 선택, 다음 홉 결정, DNS 재귀 컨텍스트 선택으로 IPv6 멀티호밍을 분리해 보여준다.
  • 실용적인 운영 기록은 하나의 연결 시도에 대한 세 가지 결정을 함께 담아야 한다. 개별 구성 요소의 기록, 심지어 성공한 요청 하나만으로는 전체 정책 면이 올바르다는 것을 증명할 수 없다.

운영자가 이 패킷이 어느 네트워크에 속하는지 물어보기 전까지는 그 패킷이 평범해 보였다. 목적지 주소는 회사 VPN에서 학습한 리졸버가 돌려준 것이었다. 소스 주소는 가정용 광대역 프리픽스에 속해 있었다. 기본 라우터는 모바일 백업 쪽으로 향하고 있었다. 모든 구성 요소가 개별적으로는 타당했다. 그 조합은 그렇지 않았다.

바로 이것이 RFC 7157,IPv6 Multihoming without Network Address Translation이 드러내는 지점이다. 2014년 3월에 IETF 합의를 반영하는 Informational RFC로 발표된 이 문서는 David Miles, Satoru Matsushima, Takashi Okimoto, Dan Wing과 함께 O. Troan을 편집자로 명시하고 있다. 공로의 성격은 정확하다. 트뢰안(Troan)은 공동 분석을 편집하는 데 기여했다. 이것이 그를 멀티호밍의 발명가로, 인용된 네트워크의 운영자로, 이후 표준의 소유자로 만들지는 않는다.

이 문서는 IPv4 NAPT의 평범한 특성에서 출발한다. 변환을 수행하는 경계 장비는 주소를 절약하는 것 이상을 한다. 흔히 소스 주소 선택, 다음 홉 결정, 그리고 선택적으로 DNS 결정을 함께 수행한다. 내부 호스트는 하나의 사설 주소만 본다. 장비는 공급자 쪽 주소와 경로의 선택을 감추고, 이름 서비스까지 중재할 수도 있다. 세 기능이 하나처럼 느껴지는 이유는 하나의 장비 안에 모두 들어 있기 때문이다.

IPv6는 이 배열의 가시성을 바꾼다. 두 공급자에 연결된 작은 사이트나 호스트는 각각 글로벌 프리픽스를 받을 수 있다. 노트북은 Wi-Fi와 모바일 접속을 동시에 유지하거나, VPN이 별도의 네임스페이스를 제공하는 동안 공용 연결을 유지할 수 있다. 종단 간 주소 지정이 더 이상 모든 흐름을 보이지 않는 변환기에 통과시킬 필요가 없다. 그러나 더 큰 주소 공간이 어떤 소스와 어느 문 그리고 어느 지도가 함께 속하는지를 결정해 주지는 않는다.

RFC 7157은 이렇게 생긴 멀티 프리픽스 요구 사항을 명명한다. 첫 패킷 이전에 호스트는 의도된 목적지에 맞는 적절한 소스 주소, 올바른 다음 홉, 올바른 재귀 DNS 서버를 필요로 한다. 공급자는 흔히 인그레스 필터링을 적용한다. 공급자 A의 소스 프리픽스를 실은 패킷이 공급자 B로 나가면, 소스와 라우터가 각각 따로는 유효하더라도 그 패킷은 폐기될 수 있다.

따라서 첫 번째 결정은 "이 인터페이스에 주소가 있는가?"가 아니다. "어느 후보 소스가 이 목적지와 프로비저닝 컨텍스트에 맞는가?"이다. RFC 6724는 기본 소스·목적지 주소 선택 알고리즘과 관리 정책 테이블을 제공한다. RFC 7157은 기본값이 특정 공급자에 맞는 소스를 결정적으로 고르지 못할 수 있다고 지적한다. RFC 7078은 주소 선택 정책을 배포하기 위한 DHCPv6 옵션을 정의한다. 이는 구성 채널을 추가하는 것이지 사용의 증명서가 아니다. DHCP 응답은 어떤 정책 바이트가 도착했는지 보여줄 수 있지만, 호스트가 그것을 수용했는지, 관련 테이블이 최신 상태로 유지되었는지, 이 패킷이 그것을 따랐는지는 보여줄 수 없다.

두 번째 결정은 문이다. 라우터 광고(Router Advertisement)는 호스트가 여러 유효한 기본 라우터를 갖게 남겨둘 수 있다. 업스트림이 소스 프리픽스 경계를 강제하거나 서로 다른 폐쇄형 서비스를 노출할 때 무작위로 하나를 고르는 것은 무해하지 않다. RFC 7157은 트래픽을 적절한 다음 홉과 연관시키는 라우팅 정보나 정책의 필요를 서술한다. 이후 RFC 8028은 멀티 프리픽스 호스트에 대한 하나의 순서 규칙을 명시한다. 소스 주소 선택이 첫 홉 선택보다 먼저 일어나며, 호스트는 선택된 소스 프리픽스를 광고한 라우터에게 패킷을 제시해야 한다. RFC 8028은 Fred Baker와 Brian Carpenter가 저자이며, Ole Troan의 중요한 텍스트 기여에 대한 감사 표시는 기여의 증거이지 저작권의 이전이 아니다.

세 번째 결정은 지도다. 호스트는 각 네트워크에서 하나의 재귀 리졸버를 학습할 수 있다. 기업 이름은 VPN 네임스페이스 안에서만 존재할 수 있고, 서비스 공급자는 자기 접속 네트워크에서만 의미가 있는 주소를 돌려줄 수 있다. 가장 먼저 응답하는 리졸버에게 모든 질문을 보내면 문법적으로는 온전하지만 운영적으로는 잘못 놓인 답을 얻을 수 있다. RFC 7157은 도메인 공간에 묶인 정책을 논의하며 RFC 6731의 DNS 선택용 DHCPv6 메커니즘을 인용한다. 리졸버의 답은 그 답을 만들어낸 컨텍스트에 계속 붙어 있어야 한다.

이 세 가지 선택에는 순서가 있지만 단일한 소유자는 없다. 애플리케이션이 목적지 이름과 의도를 표현한다. 리졸버 정책이 이름 서비스 컨텍스트를 골라 후보를 돌려준다. 호스트 정책이 소스를 고른다. 라우팅 로직이 첫 홉을 고른다. 게이트웨이와 업스트림 필터가 추가 수용 여부를 판단한다. 애플리케이션은 최종적으로 응답이나 타임아웃을 본다. 이 모든 것을 "IPv6가 됐다"로 뭉뚱그리면 다음 실패를 고치는 데 필요한 증거 자체가 사라진다.

같은 주의는 대안들에도 적용된다. RFC 7157은 종단 간 투명성을 보존하기 위해 NAT와 NPTv6는 가능한 한 피해야 한다고 말하지만, 결론에서는 NPTv6가 중간 해법으로 필요할 수 있다고도 한다. 이는 모순이 아니다. 아키텍처적 목표와 아직 완성되지 않은 배포 경로 사이의 정직한 경계다. RFC 6296은 스테이트리스 프리픽스 변환을 서술한다. 그 존재도, RFC 7157의 선호도, 모든 사이트에 대한 보편적 답을 제공하지는 않는다.

이후 작업은 우연히 섞여서는 안 되는 묶음에 이름을 붙였다. RFC 7556은 프로비저닝 도메인(Provisioning Domain)을 일관된 네트워크 구성의 집합, 즉 소스 프리픽스, 리졸버, DNS 서픽스, 기본 게이트웨이와 관련 정보로 정의한다. 이후 RFC 8801은 라우터 광고가 FQDN 기반 PvD 식별자를 실을 수 있게 하고, 시스템과 애플리케이션이 선택적 JSON 정보를 이용할 수 있게 한다. 이 메커니즘들은 연관성을 보존하는 데 도움이 된다. 그러나 식별자를 네트워크가 도달 가능하고 신뢰할 수 있으며 특정 거래에 적합하다는 증명으로 바꾸지는 않는다.

중요한 운영 대상은 초록빛 네트워크 아이콘이 아니다. 연결 시도 영수증이다. 하나의 시도에 대해 목적지 이름, 리졸버와 프로비저닝 도메인, 응답 집합과 TTL, 선택된 목적지와 소스, 소스 정책 버전, 후보 라우터와 선택된 라우터, 광고된 프리픽스와 수명, 로컬 라우트와 이웃 상태, 필터 판정, 재시도 변화, 그리고 가능하다면 업스트림이나 원격 관측을 보관하라. 벽시계 시간 드리프트 속에서도 조인이 살아남도록 하나의 시도 식별자와 단조 증가 타임스탬프를 사용하라.

각 필드는 하나의 질문에 답한다. 할당된 주소는 구성 상태를 증명할 뿐 선택을 증명하지 않는다. 선택된 소스는 로컬 결정을 증명할 뿐 업스트림 수용을 증명하지 않는다. 라우터 광고는 수신한 정보를 증명할 뿐 광고된 라우터가 패킷을 운반했음을 증명하지 않는다. DNS 응답은 하나의 컨텍스트에서 하나의 리졸버의 응답을 증명할 뿐 전달을 증명하지 않는다. 서버 응답은 한 순간 한 경로가 성공했음을 증명할 뿐 모든 폴백, 모든 목적지, 모든 네임스페이스가 올바르다는 것을 증명하지 않는다.

바로 이 구별이 트뢰안의 RFC 7157 역할의 지속적 가치다. 이 문서는 복잡성 자체를 찬양하지 않는다. 옛 장비가 무엇을 묶어 놓았는지 보여주고, 열린 아키텍처에 각 부분이 조율될 수 있을 만큼 충분한 정책을 노출할 것을 요구한다. 투명성은 통제의 부재가 아니다. 그 입력과 결정과 한계를 따로따로 검열할 수 있는 통제다.

출처