Summary

  • RFC 1383은 여러 회선에 연결된 가장자리 네트워크로 들어갈 게이트웨이를 역방향 DNS의 RX 정보에서 찾고, 내부망마다 전역 경로를 광고하지 않는 방안을 제안했다.
  • 문서의 시험 소프트웨어는 ICMP 도달 불가를 받은 뒤 DNS를 조회했다. 원문은 첫 패킷을 잃을 수 있다고 인정했고, 등록된 게이트웨이가 현재 작동한다는 보장도 없다고 봤다.

패킷을 보낸다. 라우터가 목적지 네트워크에 닿을 수 없다고 답한다. 관리 프로그램은 그 실패를 듣고 DNS에 진입점을 묻는다. Christian Huitema가 1992년 12월 발표한 RFC 1383의 실험은 이런 순서였다. 경로 실패가 경로 탐색의 신호가 된다. 첫 패킷은 그 신호를 만드는 데 쓰이고 사라질 수 있다.

당시에는 경로표가 커지고 있었다. RFC는 NSFNET에 5,000개 이상, EBONE에 7,000개 이상의 네트워크가 기록됐다고 적었다. 새 경로 광고가 늘 때마다 중계 라우터는 상태를 더 보관하고, 경로 교환은 커지며, 운영자는 정책 판단을 추가해야 했다. 계층형 주소 할당과 묶음 광고가 대안이었지만, 여러 사업자에 연결된 고객이 사업자를 바꿔도 주소를 지키고 싶다면 한 사업자의 주소 공간에 들어가는 선택은 부담스러웠다.

Huitema는 메일의 MX 기록에서 착안했다. 가장자리 영역 D에는 외부에서 보이는 두 게이트웨이 I1과 I2가 있다. 두 곳은 D 내부 길을 알지만 내부 네트워크 전체를 세계에 광고하지 않는다. 발신지나 가까운 라우터는 목적지 주소의 in-addr.arpa를 조회하고, 실험적인 RX 정보에서 진입점을 고른 뒤 그곳으로 소스 라우트를 지정한다. 초기 시험은 별도의 DNS 자료형 대신 TXT 기록 안에 RX, 선호도, 게이트웨이 IP 주소를 넣었다.

선택은 출발지 근처에서 한 번 해야 했다. 중간 라우터마다 DNS를 조회하면 모든 장비를 바꿔야 하고, 앞에서는 I1, 뒤에서는 I2를 골라 패킷이 빙빙 돌 수 있다. 두 게이트웨이는 단일 장애와 한 사업자에 대한 의존을 줄인다. 그러나 DNS 목록은 건강검진표가 아니다. 이미 닿을 수 없다고 알려진 게이트웨이는 빼야 하는데, 그 사실을 얼마나 빨리 아는지가 미해결 문제였다.

DNS 자료도 인터넷 중심부에서 읽을 수 있는 곳에 복제해야 했다. 고장 난 길의 안쪽에만 길 안내를 두면 밖에서는 찾을 수 없다. 시험 구현은 조회하는 동안 패킷을 대기열에 쌓고 남은 수명을 깎았다. RX를 찾지 못하면 목적지를 도달 불가로 기록하고 기다리던 패킷을 버렸다.

ICMP 통지를 기다리는 방식은 기존 IP 라우팅 코드를 건드리지 않으려는 선택이었다. RFC는 그 코드를 수정할 수 있다면 직접 연동하는 편이 낫다고 했다. 그래야 첫 패킷을 실패 신호로 쓰지 않는다. 공식 기록은 이 문서를 Experimental로 분류하고, 결론은 INRIA에서 코드를 개발 중이라고 밝혔다. 독립적인 네트워크 광고에 요금이 붙는다면 고객이 사업자 주소로 옮겨야 할 수 있다는 가격 문제도 제안의 배경이었다.

공유 경로표가 덜 기억하면 발신지가 더 많이 확인해야 한다. DNS는 게이트웨이의 주소를 알려 준다. 그 문이 실제 열려 있는지는 전달된 패킷이 보여 준다.

Sources