요약

  • AMS-IX는 암스테르담에서 AS6777로 라우트 서버 두 대를 운영한다. rs1.ams-ix.net과 rs2.ams-ix.net이고, 참여한다는 말은 두 대 모두와 세션을 맺는다는 뜻이다.
  • 표준이 MUST로 못 박은 동작은 NEXT_HOP을 변형 없이 넘기는 것 하나뿐이다. AS_PATH와 MED는 이유까지 적어 둔 권고 수준에 머물고, 구현은 첫 AS 검증을 꺼 줄 수 있어야 한다.
  • 공개 문서에서 책임 소재를 명시한 문장은 사실상 하나다. 프리픽스 목록과 설정이 자기 공지와 맞는지 확인하는 일은 참가자 몫이다.

라우트 서버는 패킷을 나르지 않는다. 다른 참가자가 알린 경로를 모아 자기 세션 하나로 다시 알릴 뿐이고, 실제 트래픽은 교환 지점의 스위칭 패브릭을 피어와 피어 사이로 지나간다. 이 분업이 라우트 서버를 값싸게 만든다. 스무 개의 피어와 스무 개의 세션을 유지하는 대신, 한 번의 설정으로 같은 도달 가능성을 얻는다.

AMS-IX가 공개한 것은 그 장비 두 대의 좌표와 참여 조건이다. rs1.ams-ix.net은 80.249.208.255와 2001:7f8:1::a500:6777:1, rs2.ams-ix.net은 80.249.209.0과 2001:7f8:1::a500:6777:2이며, 둘 다 AS6777로 동작한다. 참여는 선택이고 절차는 구체적이다. 두 서버에 모두 접속하고, 세션마다 알리는 프리픽스 개수와 길이를 맞추고, TCP 179번 포트로 먼저 연결을 열어야 한다. AMS-IX 라우트 서버 문서가 이 대목을 에둘러 쓰지 않는다.

표준이 남겨 둔 단 하나의 확답

RFC 7947은 교환 지점 라우트 서버를 정의하는 문서이며 2016년 9월에 나왔다. 이 문서에서 가장 강한 문장은 속성 하나에 걸려 있다. “the NEXT_HOP attribute MUST be passed unmodified”(2.2.1절). 클라이언트가 보는 넥스트 홉은 경로를 알린 피어의 패브릭 주소여야 하고, 라우트 서버는 그 값을 자기 주소로 바꿔서는 안 된다. 그래야 트래픽이 BGP를 대신 말해 준 장비를 우회해 곧장 간다.

같은 달 나온 운영 문서 RFC 7948도 경계선을 같은 자리에 긋는다. 3절은 도달 가능성 정보의 배포와 트래픽 전달을 구분한다. 라우트 서버는 패킷이 어디로 향할지를 결정하는 데 영향을 미치지만, 그 패킷을 직접 실어 나르지는 않는다.

나머지는 무르다. RFC 7947은 라우트 서버가 중계하는 경로의 AS_PATH에 자기 AS 번호를 앞에 붙이지 말아야 한다고 적는다. “SHOULD NOT prepend its own AS number”(2.2.2.1절)이며 MUST가 아니다. MULTI_EXIT_DISC도 전달은 하되 값을 고치지 말아야 한다(“SHOULD NOT modify its value.”, 2.2.3절). 2.2절은 속성 투명성을 기본값으로 놓으면서 지역 설정에 따른 예외를 명시적으로 허용하고, 2.1절은 정책 기반 필터링을 아예 허용한다.

왜 AS_PATH가 MUST가 아닌지도 RFC가 직접 설명한다. 경로 첫머리에 낯선 AS가 있으면 세션을 거부하는 구형 클라이언트가 실제로 쓰이고 있고, 의무 규칙으로 만들었다면 그 설치 기반을 버렸을 것이다. 대신 표준은 첫 AS 검증을 끌 수 있게 구현에 요구하고, 가능하면 피어 단위로 그렇게 하라고 권한다(2.2.2.2절). 더 센 보증을 포기하고 호환성을 택한 엔지니어링 타협이며, 익스체인지가 자기 경로 속성에 손대지 않을 절대 의무를 떠안았다고 읽는 사람에게는 결정적인 차이다.

운영자가 기록으로 남긴 몫

AMS-IX는 자기 몫을 문서에 적어 둔다. 중계하는 경로의 AS_PATH에 AS6777을 끼워 넣지 않고, 해당되는 곳에서는 첫 AS 검증을 꺼야 한다. 익스포트 상대는 RPSL 항목과 커뮤니티로 고른다. 0:6777은 모든 익스포트를 막고, 6777:는 지정한 피어 하나를 연다. 새 세션은 기본적으로 IRRDB와 RPKI를 함께 쓰는 필터링을 통과한다. 라우트 서버에서 배운 경로는 참가자와 그 하위 고객에게는 쓸 수 있지만, 상위 사업자나 외부 피어, 다른 교환 지점의 라우트 서버로 넘기는 것은 금지된다.

같은 문서에서 두 문장은 곱씹을 만하다. 첫째, IRRDB와 RPKI 데이터에는 유효성 보증이 없으므로 그것만 믿지 말라고 운영자가 스스로 경고한다. 기본 필터링을 설명하는 문단에 붙은 단서다. 둘째, “Participants are responsible for ensuring that their routing configuration complies with this policy.” 이 문장이 문서 전체에서 책임 소재를 명시한 유일한 대목이다. 이 페이지는 발행일을 표기하지 않으며 필자는 2026년 11월 12일 확인했다. 그 서술이 오늘도 그대로 유효한지는 이 검토로 확정되지 않는다.

참가자가 실제로 지는 부담

RFC 7948은 훨씬 앞서 같은 배분에 도달했다. 4.3절은 클라이언트가 신고한 프리픽스 목록이 실제 공지와 맞는지 확인하는 일이 “responsibility of the route server client”라고 못 박는다. 운영자 쪽 권고도 같은 절에 붙는다. 누출 완화와, 클라이언트별 인바운드 필터링이 있는 환경에서 수신 경로를 설정된 목록과 자동으로 비교하는 일이다.

그래서 이 구조에서 검증 가능한 것은 대개 참가자 쪽에 있다. 어떤 경로를 내보낼지, 어떤 커뮤니티로 상대를 열지, 첫 AS 검증을 껐는지. 라우트 서버가 NEXT_HOP을 바꾸지 않는다는 보증은 표준 문장과 운영자 서술 두 겹으로 존재하지만, AS_PATH와 MED를 실제로 손대지 않았는지 확인할 방법은 공개 문서 밖에 있다. 이 기사는 실제 설정이나 관측된 라우팅 테이블, 집행 관행을 시험하지 않았다. 확인한 페이지에서 찾은 명시적 책임 문장은 하나뿐이며, 그 부재는 다른 문서에도 그런 문장이 없다는 증명이 아니라 이번에 검토한 페이지에 대한 관찰이다.

두 서버의 기본값이 완전히 같게 동작하는지도 이 페이지로는 확정되지 않는다. 필터링 기본값과 커뮤니티 익스포트 제어가 rs1과 rs2에서 동일하게 적용되는지는 별도의 관측이 필요한 문제다.

남는 것

라우트 서버는 자기가 무엇을 하느냐보다 무엇을 하지 않느냐로 정의되는 장비다. 패킷을 나르지 않고, 자기 AS를 끼워 넣지 않고, 속성을 고치지 않는다. 그 금지 목록 가운데 의무로 못 박힌 것은 하나뿐이고 나머지는 이유와 함께 완곡하게 적혀 있다. 이 완곡함이 값을 치르는 순간은 참가자가 자기 경로가 남의 필터에서 어떻게 보일지 계산할 때다.

BTW 디렉터리의 AMS-IX 암스테르담 라우트 서버 항목이 이 대상의 식별자다. 라우트 서버를 ‘문서로 권한이 제한된 관리자’로 읽는 관점은 필자의 구성이며, IETF나 AMS-IX의 공식 입장이 아니다.