요약

  • 듀얼 스택은 DNS와 도달 가능성 사이의 간극을 드러냈습니다. A 또는 AAAA 레코드는 후보 주소를 제공할 뿐, 전송 계층 연결이 현재 경로를 통과할 수 있다는 증거가 아닙니다.
  • RFC 6555는 IPv6를 선호 주소군으로 유지하면서도 그 우선순위가 사용자를 지연시킬 수 있는 권한을 한정했습니다. RFC 8305는 이 방식을 비동기 DNS, RFC 6724 정렬, 주소군 교차 배치, 시차를 둔 시도로 다듬었습니다.
  • 가장 먼저 완료된 설정은 그 연결에만 승리합니다. 이 메커니즘은 사용자 경험을 개선하는 동시에, 운영자에게 패배한 주소군의 지속적인 결함을 가릴 가능성을 갖습니다.

주소는 참이었지만 경로는 아니었습니다

전환 문제는 그것에 경쾌한 이름이 붙기 훨씬 전부터 드러나 있었습니다. 1994년에 발표된RFC 1671은 DNS가 대안 주소를 반환하지만 그중 하나의 경로가 블랙홀을 통과할 때 듀얼 스택 호스트가 무엇을 해야 하는지 물었습니다. 호스트, 터널, 피어링 또는 중간 네트워크가 현재 그 프로토콜을 전달할 수 없는 상태에서도 레코드는 정상적으로 공개되어 있을 수 있었습니다.

직렬 연결 로직은 그 불일치를 비싸게 만들었습니다. 정책이 IPv6를 먼저 두면, 애플리케이션은 SYN을 보내고 재전송을 기다린 뒤에야 동작하는 IPv4 주소를 시도할 수 있었습니다. IPv4 전용 클라이언트는 반응이 빠른 반면, 더 유능해 보이는 듀얼 스택 클라이언트는 고장 난 것처럼 보였습니다. 사용자와 관리자에게는 명백한 탈출구가 있었습니다. IPv6를 비활성화하는 것입니다. 실패의 벌이 사람들에게 그것을 끄도록 훈련시키는 전환 메커니즘은 자신의 목적지에 거슬리는 일을 하고 있었습니다.

끌리는 해법들도 빈약했습니다. 별도의ipv6.example이름은 공유 네임스페이스를 갈라놓을 것입니다. 정적 화이트리스트는 모든 클라이언트 경로에서 일시적인 실패를 따라갈 수 없었습니다. DNS는 주소를 광고할 수 있지만, 이 순간 이 클라이언트에서 시작되는 경로를 관찰할 수는 없었습니다. 빠져 있는 사실은 연결 시점에 존재했습니다.

우선순위가 출발선 우위가 되었습니다

RFC 6555는 2012년 해피 아이볼을 표준화했습니다. 그 핵심은 IPv4와 IPv6를 동등하다고 선언하는 것이 아니었습니다. 호스트의 주소 정책은 여전히 보통 IPv6를 선호합니다. 알고리즘은 그저 그 우선순위가 사용자의 인내에 대한 긴 독점 임대가 되는 것을 거부했습니다.

클라이언트는 선호 후보로 시작합니다. 그것이 신속히 완료되지 않으면, 첫 시도가 진행 중인 상태로 남아 있을 수도 있으면서 다른 주소군으로 또 하나의 시도가 시작됩니다. 시도에는 간격이 부여됩니다. SYN 하나하나가 서버 상태, 방화벽 항목, NAT 포트, 네트워크 용량을 소모할 수 있기 때문입니다. 한 연결이 성공하면 나머지 시도는 버려집니다. 우선순위는 누가 먼저 시작하는지를 결정하고, 측정된 설정은 이 연결을 누가 처리하는지를 결정합니다.

이 구분은 기술적으로만이 아니라 경제적으로도 중요합니다. 순수한 최속 경로 경쟁은 불필요한 트래픽을 공유 IPv4 주소와 변환기에 계속 두게 만들어, 레거시 용량을 줄이기 어렵게 합니다. 절대적인 IPv6 규칙은 사용자가 통제할 수 없는 결함에 대한 대가를 부과할 수 있습니다. 해피 아이볼은 전환 저울에 가벼운 손가락 하나를 얹고, 실패의 증거가 그것을 다시 들어 올리도록 내버려두었습니다.

RFC 6555는 기억도 잠정적인 것으로 취급했습니다. 클라이언트는 한 주소군이 실패했다는 것을 기억해 같은 지연을 반복하지 않을 수 있지만, 선호 주소군을 주기적으로 다시 시도해야 했습니다. 사양은 대략 10분 정도를 제안했고, 장치가 새 네트워크에 접속하면 초기화되도록 했습니다. 어제 망가진 터널이 오늘의 접속에 대한 권위를 가지지는 않습니다.

버전 2는 DNS를 경주에 편입시켰습니다

2017년까지의 배포 경험 덕분에RFC 8305는 첫 설명을 더 완전한 파이프라인으로 대체할 수 있었습니다. A와 AAAA 질의는 거의 동시에 시작되며, AAAA가 먼저입니다. 애플리케이션은 둘을 기다릴 필요가 없습니다. 우연히 A가 먼저 도착하면, 권장되는 50밀리초의 해석 지연이 AAAA에 IPv6의 선두를 지키게 하는 짧은 기회를 줍니다. 쓸만한 AAAA가 도착하지 않으면 IPv4 작업을 시작할 수 있습니다.

클라이언트는 이어서RFC 6724를 사용해 주소를 정렬합니다. 그 정책은 사용 가능한 소스 주소, 범위, 레이블과 다른 호스트 지식을 고려합니다. 정렬은 연결 가능성 증명서가 아닙니다. 정보에 입각한 순서를 산출할 뿐입니다.

해피 아이볼 v2는 주소군 교차 배치로 그 순서를 변형합니다. 목록이 IPv6로 시작하면, 보통 가장 좋은 IPv4 후보가 두 번째 자리로 옮겨집니다. 이렇게 하면 하나의 IPv4 주소에 기회를 주기 전에 다섯 개의 도달 불가능한 AAAA 주소를 기다리는 일을 피합니다. 이 절차는 각 프로토콜의 대표 하나가 아니라 후보 집합 전체를 경주시킵니다.

시도는 한 번에 하나씩 시작되며 겹칩니다. RFC 8305는 250밀리초를 기본 연결 시도 지연으로 권장합니다. 다음 시도를 10밀리초 이내에 시작하는 것은 금지되고, 100밀리초가 최소, 2초가 최대로 권장됩니다. 이것들은 경험에 근거한 설정 가능한 한계이지 자연법칙이 아닙니다. 문서는 네트워크가 변함에 따라 이들이 진화할 것으로 기대합니다.

이력은 순서를 다듬을 수 있지만, 정당한 경계 안에서만 그럴 수 있습니다. 예상 왕복 시간이나 이전에 사용된 주소가 선택에 영향을 줄 수 있습니다. 그 기억은 네트워크 인터페이스 사이로 새어 나가서는 안 되며, 접속이 바뀌면 지워져야 합니다. 호텔 네트워크의 실패가 노트북이 집에 도착한 뒤 IPv6를 격하해서는 안 됩니다.

승자가 보여주는 것은 겉보기보다 적습니다

가장 먼저 성공한 시도는 일반적으로 전송 계층 핸드셰이크가 완료되었다는 것만을 증명합니다. 그것은 TLS가 검증될 것, HTTP가 동작할 것, 모든 주소 뒤의 애플리케이션이 일관될 것, 큰 패킷이 경로를 통과할 것을 증명하지 않습니다. RFC 8305는 핸드셰이크 이후의 경로 MTU 실패가 숨겨진 채 남을 수 있다고 명시합니다.

승리한 주소가 서버를 인증하지도 않습니다. DNS 응답은 바뀔 수 있으며, 하나의 호스트명에 대한 연속된 연결은 서로 다른 IP 주소를 사용할 수 있습니다. 신원은 경주 결과가 아니라 적절한 애플리케이션 보안 프로토콜에 속합니다.

가장 중요한 한계는 운영에 있습니다. IPv6가 매일 실패하고 IPv4가 1/4초 만에 이기면, 사용자는 불평하지 않을 수 있습니다. 클라이언트는 장애를 작은 지연 증분으로 바꾸어 놓았습니다. 그것은 훌륭한 복원력이지만 나쁜 장애 가시성입니다. 그래서 RFC 8305는 모든 주소군에 대한 독립적인 모니터링을 요구합니다.

해피 아이볼은 IPv4 대 IPv6 논쟁을 종결하지 않았습니다. 그것은 정책과 관찰 사이에 더 나은 경계를 설계했습니다. 우선순위는 첫 실험을 고를 수 있습니다. 그러나 반대 증거를 무기한 억제해서는 안 됩니다.

출처와 한계

닫힌 기록은RFC 1671,RFC 6555,RFC 6724및RFC 8305입니다. 이 문서들은 문제, 정렬 규칙, 연결 알고리즘, 권장 한계와 명시된 한계점을 정합니다. 그러나 현재 구현 점유율, 보편적으로 최적인 지연 값, 또는 한 주소군이 전 세계적으로 더 건강하다는 증거를 제공하지는 않습니다.