IANA

인터넷 프로토콜이 쓰는 번호와 이름을 한 곳에서 배정하는 일입니다. 배정한 값을 목록으로 모아 두고 누구나 볼 수 있게 공개하는 것까지가 그 일입니다. 포트 80 이 어느 서비스의 자리인지도 이 목록이 정합니다.

상세

한 건물에 사무실이 여럿이면 관리실이 호실 번호를 하나씩 매깁니다. 두 사무실에 같은 번호가 가면 우편물이 엉키기 때문입니다. 관리실은 번호를 다 매기면 끝나지만, 이쪽은 매긴 값을 오래 유지하는 일과 목록을 계속 공개하는 일이 뒤에 남습니다.

IANA(Internet Assigned Numbers Authority)는 인터넷 프로토콜의 기술 파라미터를 배정하고 그 배정을 공표하는 기술 팀을 가리키는 이름입니다. RFC(Request for Comments) 2860 은 이것을 예전부터 써 온 전통적인 이름이라고 적습니다. 같은 문서는 이 각서가 체결된 2000년 기준으로 그 기술 팀이 ICANN(Internet Corporation for Assigned Names and Numbers)의 일부라고 밝힙니다. 그 뒤로 운영 주체가 다시 바뀐 사정은 배경에서 다룹니다.

배정을 임의로 하지는 않습니다. RFC 2860 은 IANA 가 RFC 에 명시된 기준과 절차가 지시하는 대로만 인터넷 프로토콜 파라미터를 배정하고 등록한다고 적습니다. 기준이 명시되지 않았거나 애매한 경우에는 IANA 가 전통적으로 등록해 온 관행을 그대로 이어 갑니다. IESG(Internet Engineering Steering Group)가 달리 지시하면 그때는 지시가 앞섭니다. 기술적 다툼이 생기면 IANA 는 IESG 한 곳에서만 기술 지침을 구합니다.

배정한 결과는 공개가 전제입니다. RFC 2860 은 현재 배정 하나하나의 정보를 온라인으로 무료로 공개하라고 적습니다. 신청 창구도 온라인으로 열어 둡니다. 거절은 적법한 기술적 사유로만 할 수 있습니다. IAB(Internet Architecture Board)의 동의 없이는 배정에 요금을 매기지 않습니다.

flowchart TD
    A[신청] --> B[온라인 신청 창구]
    B --> C{기술 요건에 맞나}
    C -->|맞음| D[배정과 등록]
    C -->|안 맞음| E[거절]
    D --> F[온라인 무료 공개]

신청이 들어오면 기술 요건에 맞는지를 봅니다. 맞으면 배정해서 등록합니다. 등록한 내용은 다시 온라인 공개로 이어집니다.

이 절차가 무엇을 지키려는 것인지는 RFC 7500 이 일곱 가지로 적습니다. 앞의 넷은 배정된 값 자체를 봅니다. 같은 프로토콜 식별자를 두 가지 용도로 쓰지 않는 유일성, 배정이 오래가는 안정성, 절차에 뜻밖의 단계가 끼어들지 않는 예측 가능성, 잘 알려진 자리에 두어 누구나 자유롭게 얻게 하는 공개성입니다. 뒤의 셋은 등록부를 굴리는 방식을 봅니다. 배정과 등록의 정책을 정하는 과정은 관심 있는 모든 당사자에게 열려 있어야 합니다. 같은 문서는 등록부와 거기 딸린 정책이 투명한 방식으로 만들어지기를 권합니다. 정책 수립과 등록부 운영은 영향을 받는 공동체에 책임을 지는 자리에 있어야 합니다.

배경

처음에는 배정 목록 자체가 RFC 문서였습니다. IANA 는 1977년 11월부터 1994년 10월까지 인터넷 프로토콜 파라미터 배정 표를 「Assigned Numbers」라는 제목의 RFC 로 주기적으로 냈습니다. 그중 가장 최신판은 표준(Standard) 지위를 가진 문서였습니다. 거기에는 그 지위를 나타내는 STD 2 라는 번호가 붙었습니다. 그 시점의 가장 최신판이 RFC 1700 입니다.

문서로 찍어 돌리는 방식으로는 목록이 낡는 것을 못 막습니다. RFC 1700 은 스스로를 진행 중인 배정 과정의 스냅숏이라고 적습니다. 실제 값은 온라인 텍스트 파일 묶음에서 최신 상태로 유지됐습니다. 그 파일들을 이어 붙인 뒤 최소한의 서식만 덧댄 것이 그 RFC 였습니다. 정본은 이미 파일 쪽에 있었던 셈입니다. 그 뒤로 이 RFC 계열은 웹으로 접근하는 온라인 데이터베이스가 대신했습니다. RFC 3232 가 그 사실을 기록했습니다. 같은 문서가 RFC 1700 을 공식 폐기했습니다. 상태는 Historic 으로 바뀌었습니다. 값이 불완전하며 어떤 경우에는 틀렸을 수 있다는 말도 함께 적혔습니다. 다만 같은 문서는 이 계열이 새 IANA 조직의 손에서 앞으로 되살아날 것으로 본다고 덧붙였습니다.

이름과 소속은 문서로 따로 굳었습니다. RFC 1700 시절의 IANA 는 ISOC(Internet Society)와 FNC(Federal Network Council)에게서 헌장을 받아 인터넷 프로토콜 파라미터 배정을 맡는 중앙 조정자였습니다. 2000년 3월에는 IETF(Internet Engineering Task Force)와 ICANN 이 IANA 의 기술 업무를 두고 합의각서에 서명했습니다. 그 각서 본문을 기록해 남긴 것이 RFC 2860 입니다.

운영 주체는 그 뒤로도 한 번 더 바뀌었습니다. iana.org 는 지금 IANA 기능을 제공하는 곳이 PTI(Public Technical Identifiers, 퍼블릭 테크니컬 아이덴티파이어스)라고 적습니다. PTI 는 ICANN 의 계열사(affiliate)입니다. RFC 2860 이 적은 2000년의 "ICANN 의 일부"와는 다른 자리입니다 — 그때는 기술 팀이 ICANN 안으로 들어갔고, 지금은 ICANN 이 별도 법인인 PTI 를 세워 그 팀에 이 기능을 맡깁니다.

갈래

IANA 가 다루는 식별자 공간은 세 갈래로 갈립니다. 가르는 축은 기술 고려만으로 값이 정해지느냐입니다. RFC 2860 은 도메인 이름 배정과 IP(Internet Protocol) 주소 블록 배정 두 가지를 두고, IETF 가 정하는 기술 고려에 더해 정책 사안이 따로 있다고 적습니다. 그 정책 사안은 각서의 범위 밖이라고 못 박습니다. 나머지 프로토콜 파라미터는 각서 본문이 정면으로 다룹니다. iana.org 첫 화면도 도메인 이름 · 번호 자원 · 프로토콜 배정 세 구획으로 나뉘어 있습니다.

도메인 이름

DNS(Domain Name System) 루트 존을 관리하는 갈래입니다. ccTLD(country code Top-Level Domain, 국가 코드 최상위 도메인)와 gTLD(generic Top-Level Domain, 일반 최상위 도메인)를 배정하는 일, 그리고 .int 와 .arpa 존 같은 기능이 여기 들어갑니다.

배정 자체에 정책 사안이 얹히는 자리라 각서의 기술 업무 규정 밖에 놓입니다. 다만 역방향 DNS 조회용 도메인 이름처럼 기술 용도의 배정은 정책 사안으로 보지 않습니다. 그런 배정에는 기술 업무 규정이 그대로 걸립니다.

번호 자원

전 세계 IP 주소 공간과 AS(Autonomous System) 번호 공간을 조정하는 갈래입니다. 지역 인터넷 레지스트리에 주소를 할당하는 일이 여기 들어갑니다.

IP 주소 블록 배정 역시 정책 사안이 얹히는 자리입니다. 멀티캐스트나 애니캐스트 같은 특수 주소 블록 배정과 실험용 배정은 정책 사안으로 보지 않습니다. 그쪽에는 기술 업무 규정이 그대로 적용됩니다.

프로토콜 배정

많은 인터넷 프로토콜이 쓰는 프로토콜 이름과 번호 레지스트리를 모아 두는 중앙 저장소입니다.

RFC 2860 이 정면으로 규정하는 자리가 여기입니다. RFC 가 정한 기준과 절차에 따라서만 배정하고 등록하는 대상이 이 갈래입니다.

예시

등록부의 한 줄은 값과 이름, 그리고 그 값을 정한 근거 문서를 한 자리에 붙여 둡니다. 레지스트리마다 칸 구성이 다릅니다.

HTTP(HyperText Transfer Protocol) 상태 코드 레지스트리

429,Too Many Requests,[RFC6585]

값 429, 이름 Too Many Requests, 근거 문서 RFC 6585 세 칸입니다. 코드 하나에 이름 하나와 근거 문서 하나가 붙는 가장 단출한 모양입니다.

서비스 이름과 포트 번호 레지스트리

http,80,tcp,World Wide Web HTTP,[IESG],[IETF_Chair],,2021-10-01,[RFC9110],,,Defined TXT keys: u=<username> p=<password> path=<path to document>

서비스 이름 http, 포트 번호 80, 전송 프로토콜 tcp 가 앞 세 칸입니다. 뒤로 설명과 담당자, 갱신 날짜, 근거 문서 RFC 9110 이 이어집니다. 포트 번호 하나가 서비스 이름과 전송 프로토콜에 함께 묶여 있습니다.

미디어 타입 레지스트리

html | text/html | [W3C][Robin_Berjon]

이름 html, 템플릿 text/html, 근거가 W3C(World Wide Web Consortium)입니다. 근거 칸이 RFC 로 묶이지 않는 줄도 있다는 것을 이 행이 보여 줍니다.

문자 집합 레지스트리

EUC-KR | EUC-KR | 38 | [RFC1557] (see also KS_C_5861-1992) | [RFC1557][Woohyong_Choi] | csEUCKR

이름 EUC-KR 에 MIBenum 38 이라는 번호가 따로 붙습니다. 근거 문서는 RFC 1557 입니다. KS_C_5861-1992 를 함께 보라는 말이 옆에 적혀 있습니다. 줄 끝의 csEUCKR 은 별칭입니다.

관련 항목

IANA 업무를 규율하는 조직·문서

ICANN · IETF · IESG · IAB · ISOC · FNC(Federal Network Council) · PTI · IRTF(Internet Research Task Force) · RFC · RFC 8126 · 인터넷 표준

도메인 이름 배정을 이루는 구성 요소

도메인 이름 · DNS · 루트 존 · TLD

번호 자원 배정을 이루는 구성 요소

번호 자원 · AS 번호 · IP 주소 · 지역 인터넷 레지스트리

프로토콜 파라미터 배정을 이루는 구성 요소

프로토콜 배정 · 프로토콜 파라미터 · 데이터베이스 · 포트 번호 · 미디어 타입 · 문자 집합 · HTTP 상태 코드 · HTTP · MIBenum · EUC-KR

레지스트리 항목의 근거가 되는 문서·기구

RFC 9110 · W3C · RFC 6585 · RFC 1557 · KS_C_5861-1992