본문으로 이동

IPv4

위키백과, 우리 모두의 백과사전.
인터넷 프로토콜 버전 4
Internet Protocol version 4
프로토콜 스택
IPv4 패킷
목적인터네트워킹 프로토콜
개발DARPA
도입일1980년(46년 전)(1980)
영향을 받음IPv6
OSI 계층네트워크 계층
RFC760, 791

인터넷 프로토콜 버전 4(Internet Protocol version 4, IPv4)는 독립형 사양으로서 인터넷 프로토콜(IP)의 첫 번째 버전이다. 인터넷 및 기타 패킷 교환 네트워크에서의 표준 기반 인터네트워킹 방식의 핵심 프로토콜 중 하나이다. IPv4는 1982년 SATNET에서, 1983년 1월 ARPANET에서 운영을 위해 처음으로 배포된 버전이다. 후속 버전인 IPv6(Internet Protocol version 6)의 지속적인 배포에도 불구하고,[1] 오늘날까지 대부분의 인터넷 트래픽을 라우팅하는 데 여전히 사용되고 있다.[2]

IPv4는 4,294,967,296(232)개의 고유 주소를 제공하는 32비트 주소 공간을 사용하지만, 큰 블록들은 특수 네트워킹 목적으로 예약되어 있다.[3][4] 이러한 고유 주소의 양은 전 세계 인터넷의 요구를 충족하기에 충분하지 않으며, 이로 인해 IPv6로 전환되는 과정에서 IPv4 주소 고갈이라는 중대한 문제가 발생했다.

목적

[편집]

인터넷 프로토콜("IP")은 인터넷 프로토콜 스위트의 인터넷 계층에서 인터네트워킹을 정의하고 가능하게 하는 프로토콜이다. 이는 인터넷에 전 세계 규모의 논리적 주소 체계를 부여하여, 소스 호스트로부터 다른 네트워크에 있는 목적지 호스트에 한 홉 더 가까운 다음 라우터로 IP 데이터 패킷의 라우팅을 가능하게 한다.

IPv4는 비연결형 프로토콜이며, 전송을 보장하지 않고 적절한 순서 보장이나 중복 전송 방지를 확약하지 않는 최선 노력 전달 모델로 작동한다. 이러한 측면은 전송 제어 프로토콜(TCP)이나 QUIC 프로토콜과 같은 상위 계층 전송 프로토콜에 의해 처리될 수 있다.

역사

[편집]

TCP/IP의 초기 버전은 TCP/IPv3를 통해 통합된 사양이었다. IPv4에 이르러 인터넷 프로토콜은 별개의 사양이 되었다.[5]

인터넷 프로토콜 버전 4는 IETF 간행물 RFC 791(1981년 9월)에 설명되어 있으며, 1980년 1월의 이전 정의(RFC 760)를 대체했다. 1982년 3월, 미국 국방부는 모든 군용 컴퓨터 망의 표준으로 인터넷 프로토콜 스위트(TCP/IP)를 채택하기로 결정했다.[6]

주소 공간 고갈

[편집]
IPv4 주소 고갈 타임라인

1980년대 후반에 이르러, 사용 가능한 IPv4 주소 풀이 네트워크의 원래 설계 당시 예상하지 못했던 속도로 고갈되고 있다는 점이 분명해졌다.[7] 1990년대부터 주소 고갈을 가속화한 주요 요인으로는 IP 데이터 서비스를 이용하는 노트북 컴퓨터, 개인 정보 단말기(PDA), 스마트폰 등 모바일 컴퓨팅 기기를 사용하는 인터넷 사용자 수의 급격한 증가가 포함되었다. 또한 초고속 인터넷 접속은 상시 접속 기기를 기반으로 했다. 고갈의 위협은 다음과 같은 여러 구제 기술의 도입을 촉진했다.

1990년대 중반까지 NAT는 지역 및 로컬 인터넷 레지스트리의 엄격한 사용 기반 할당 정책과 함께 네트워크 접속 제공자 시스템에서 널리 사용되었다.

IANA가 관리하는 인터넷의 기본 주소 풀은 2011년 2월 3일 마지막 5개 블록이 5개의 대륙별 인터넷 레지스트리(RIR)에 할당되면서 고갈되었다.[8][9] APNIC은 제한된 정책하에 할당되는 IPv6 전환 기술용으로 예약된 소량의 주소 공간을 제외하고, 2011년 4월 15일에 지역 풀이 고갈된 첫 번째 RIR이 되었다.[10]

주소 고갈에 대한 장기적인 해결책은 1998년에 사양화된 인터넷 프로토콜의 새로운 버전인 IPv6였다.[11] 이는 엄청나게 증가된 주소 공간을 제공할 뿐만 아니라, 인터넷 전반에 걸쳐 개선된 경로 집계(route aggregation)를 가능하게 하며, 최종 사용자에게 최소 264개의 호스트 주소를 갖는 대규모 서브넷 할당을 제공한다. 그러나 IPv4는 IPv6와 직접적으로 상호 운용되지 않으므로, IPv4 전용 호스트는 IPv6 전용 호스트와 직접 통신할 수 없다. 2004년부터 시작된 6bone 실험 네트워크의 단계적 중단과 함께, 2006년부터 IPv6의 영구적이고 공식적인 배포가 시작되었다.[12] IPv6 배포의 완료에는 상당한 시간이 걸릴 것으로 예상되므로,[13] 호스트가 두 버전의 프로토콜을 모두 사용하여 인터넷에 참여할 수 있도록 하는 중간 단계의 IPv6 전환 메커니즘이 필요하다.

주소 지정

[편집]
4단위 점으로 구분된 IPv4 주소 표현을 이진법 값으로 분해한 모습

IPv4는 32비트 주소를 사용하여 주소 공간을 4294967296(232)개의 주소로 제한한다.

IPv4는 사설망(224 + 220 + 216 ≈ 1,800만 개 주소) 및 멀티캐스트 주소(228 ≈ 2억 6,800만 개 주소)를 위해 특수 주소 블록을 예약해 두고 있다.

주소 표현

[편집]

IPv4 주소는 32비트 정수 값을 나타내는 모든 표기법으로 표현될 수 있다. 가장 흔히 점-십진 표기법(dot-decimal notation)으로 작성되는데, 이는 주소의 4개 옥텟을 각각 십진법 숫자로(앞자리에 불필요한 0 없이) 표현하고 마침표로 구분하는 방식이다.

예를 들어, 그림의 4단위 점 IP 주소(172.16.254.1)는 32비트 십진법 숫자 2886794753을 나타내며, 이는 십육진법 형식으로 0xAC10FE01이다.

CIDR 표기법은 주소 뒤에 슬래시 문자(/)와 라우팅 접두사(서브넷 마스크)에서 연속된 1 비트의 개수를 덧붙여 주소와 라우팅 접두사를 간결한 형식으로 결합한다.

클래스 기반 네트워킹이 시행되던 시기에는 다른 주소 표현 방식도 흔히 사용되었다. 예를 들어, 루프백 주소 127.0.0.1은 네트워크 마스크가 8비트이고 호스트 번호가 24비트인 클래스 A 네트워크에 속하므로 흔히 127.1로 표기되었다. 점 표기법에서 주소에 4개 미만의 숫자가 지정된 경우, 마지막 값은 주소를 4개 옥텟으로 채우는 데 필요한 만큼의 바이트를 가진 정수로 취급되었다. 따라서 주소 127.65530은 127.0.255.250과 동일하다.

할당

[편집]

IPv4의 원래 설계에서 IP 주소는 두 부분으로 나뉘었다. 네트워크 식별자는 주소의 최상위 옥텟이었고, 호스트 식별자는 주소의 나머지 부분이었다. 후자는 나머지 필드(rest field)라고도 불렸다. 이 구조는 최대 256개의 네트워크 식별자만을 허용했는데, 이는 곧 부적절하다는 것이 밝혀졌다.

이 한계를 극복하기 위해 1981년에 최상위 주소 옥텟을 재정의하여 네트워크 클래스를 만들었으며, 이 시스템은 나중에 클래스 기반 네트워킹으로 알려지게 되었다. 개정된 시스템은 5개의 클래스를 정의했다. 클래스 A, B, C는 네트워크 식별을 위한 비트 길이가 달랐다. 주소의 나머지 부분은 이전과 마찬가지로 네트워크 내의 호스트를 식별하는 데 사용되었다. 클래스마다 필드의 크기가 달랐기 때문에 각 네트워크 클래스는 호스트 주소 지정 용량이 달랐다. 호스트 주소 지정을 위한 3개의 클래스 외에도, 멀티캐스트 주소 지정을 위한 클래스 D와 미래의 애플리케이션을 위해 예약된 클래스 E가 정의되었다.

기존의 클래스 기반 네트워크를 서브넷으로 나누는 작업은 1985년 RFC 950의 발표와 함께 시작되었다. 이러한 분할은 1987년 RFC 1109에서 가변 길이 서브넷 마스크(VLSM)의 도입으로 더욱 유연해졌다. 1993년, 이 작업을 바탕으로 RFC 1517에서 Classless Inter-Domain Routing(CIDR)이 도입되었으며,[14] 이는 (최상위 비트부터) 비트의 수를 /24와 같이 표현하게 되었고, 이와 대조적으로 기존의 클래스 기반 체계는 '클래스풀(classful)'이라 불리게 되었다. CIDR은 더 작거나 큰 주소 블록을 사용자에게 할당할 수 있도록 모든 주소 공간의 재분할을 허용하도록 설계되었다. CIDR에 의해 생성된 계층 구조는 IANA(Internet Assigned Numbers Authority)와 대륙별 인터넷 레지스트리(RIR)에 의해 관리된다. 각 RIR은 IP 주소 할당에 대한 정보를 제공하는 공개 검색 가능 WHOIS 데이터베이스를 유지 관리한다.

특수 용도 주소

[편집]

국제 인터넷 표준화 기구(IETF)와 IANA는 다양한 특수 목적을 위해 일반적인 사용으로부터 여러 예약된 IP 주소를 제한해 왔다.[4] 특히 이러한 주소는 멀티캐스트 트래픽 및 사설망에서의 제한 없는 사용을 위한 주소 공간을 제공하는 데 사용된다.

특수 주소 블록
주소 블록 (CIDR) 주소 범위 주소 개수 범위 설명
0.0.0.0/8 0.0.0.0–0.255.255.255 16777216 소프트웨어 현재(로컬, "이") 네트워크[4]
10.0.0.0/8 10.0.0.0–10.255.255.255 16777216 사설망 사설망 내의 로컬 통신에 사용[15]
100.64.0.0/10 100.64.0.0–100.127.255.255 4194304 사설망 캐리어급 NAT를 사용할 때 서비스 제공자와 가입자 간의 통신을 위한 공유 주소 공간[16]
127.0.0.0/8 127.0.0.0–127.255.255.255 16777216 호스트 Localhost에 대한 루프백 주소로 사용[4]
169.254.0.0/16 169.254.0.0–169.254.255.255 65536 서브넷 DHCP 서버 등으로부터 IP 주소를 얻지 못했을 때, 단일 링크의 두 호스트 사이에서 사용되는 링크-로컬 주소[17]
172.16.0.0/12 172.16.0.0–172.31.255.255 1048576 사설망 사설망 내의 로컬 통신에 사용[15]
192.0.0.0/24 192.0.0.0–192.0.0.255 256 사설망 IETF 프로토콜 할당, DS-Lite (/29)[4]
192.0.2.0/24 192.0.2.0–192.0.2.255 256 문서화 TEST-NET-1로 할당, 문서화 및 예제용[18]
192.88.99.0/24 192.88.99.0–192.88.99.255 256 인터넷 예약됨.[19] 이전에는 IPv6 to IPv4 릴레이용으로 사용됨[20] (2002::/16 주소 블록 포함).
192.168.0.0/16 192.168.0.0–192.168.255.255 65536 사설망 사설망 내의 로컬 통신에 사용[15]
198.18.0.0/15 198.18.0.0–198.19.255.255 131072 사설망 두 개의 분리된 서브넷 간의 상호 네트워크 통신 벤치마크 테스트에 사용[21]
198.51.100.0/24 198.51.100.0–198.51.100.255 256 문서화 TEST-NET-2로 할당, 문서화 및 예제용[18]
203.0.113.0/24 203.0.113.0–203.0.113.255 256 문서화 TEST-NET-3로 할당, 문서화 및 예제용[18]
224.0.0.0/4 224.0.0.0–239.255.255.255 268435456 인터넷 멀티캐스트용으로 사용 중[22] (구 클래스 D 네트워크)
233.252.0.0/24 233.252.0.0–233.252.0.255 256 문서화 MCAST-TEST-NET으로 할당, 문서화 및 예제용 (위의 멀티캐스트 공간의 일부임)[22][23]
240.0.0.0/4 240.0.0.0–255.255.255.254 268435455 인터넷 미래 사용을 위해 예약됨[24] (구 클래스 E 네트워크)
255.255.255.255/32 255.255.255.255 1 서브넷 제한된 브로드캐스트 목적지 주소로 예약됨[4]

사설망

[편집]

IPv4에서 정의된 약 40억 개의 주소 중, RFC 1918에 명시된 바와 같이 3개 범위의 약 1,800만 개 주소가 사설망에서 사용하기 위해 예약되어 있다. 이 범위의 주소를 가진 패킷은 공용 인터넷에서 라우팅할 수 없으며, 모든 공용 라우터에서 무시된다. 따라서 사설 호스트는 공용 네트워크와 직접 통신할 수 없으며, 이를 위해 라우팅 게이트웨이에서 네트워크 주소 변환(NAT)이 필요하다.

예약된 사설 IPv4 네트워크 범위[15]
이름CIDR 블록주소 범위주소 개수클래스풀 설명
24비트 블록10.0.0.0/810.0.0.0 – 10.255.255.25516777216단일 클래스 A
20비트 블록172.16.0.0/12172.16.0.0 – 172.31.255.2551048576클래스 B 블록 16개의 연속 범위
16비트 블록192.168.0.0/16192.168.0.0 – 192.168.255.25565536클래스 C 블록 256개의 연속 범위

두 개의 사설망(예: 두 개의 지사)은 공용 인터넷을 통해 직접 상호 운용할 수 없으므로, 공용 네트워크를 통한 전송 중에 사설 주소를 포함하는 헤더를 포함한 패킷을 프로토콜 계층으로 캡슐화하는 가상사설망(VPN) 또는 IP 터널을 통해 인터넷을 가로질러 두 네트워크를 연결해야 한다. 또한, 캡슐화된 패킷은 데이터를 보호하기 위해 공용 네트워크를 통한 전송 시 암호화될 수 있다.

링크-로컬 주소 지정

[편집]

RFC 3927은 링크-로컬 주소 지정을 위해 특수 주소 블록 169.254.0.0/16을 정의한다. 이 주소들은 이를 사용하는 호스트에 직접 연결된 링크(예: 로컬 네트워크 세그먼트 또는 점대점 연결)에서만 유효하다. 이 주소들은 라우팅할 수 없다. 사설 주소와 마찬가지로, 이 주소들은 인터넷을 통과하는 패킷의 소스 또는 목적지가 될 수 없다. 이 주소들은 주로 호스트가 DHCP 서버나 다른 내부 구성 방법으로부터 IP 주소를 얻을 수 없을 때 주소 자동 구성(Zeroconf)을 위해 사용된다.

이 주소 블록이 예약되었을 당시에는 주소 자동 구성에 대한 표준이 없었다. 마이크로소프트는 수백만 대의 기기에 배포되어 사실상 표준이 된 Automatic Private IP Addressing(APIPA)이라는 구현체를 만들었다. 수년 후인 2005년 5월, IETF는 "Dynamic Configuration of IPv4 Link-Local Addresses"라는 제목의 RFC 3927에서 공식 표준을 정의했다.

루프백

[편집]

클래스 A 네트워크 127.0.0.0(비클래스 네트워크 127.0.0.0/8)는 루프백을 위해 예약되어 있다. 소스 주소가 이 네트워크에 속하는 IP 패킷은 호스트 외부로 나타나서는 안 된다. 루프백 소스 또는 목적지 주소를 가진 패킷이 루프백이 아닌 인터페이스에서 수신되면 반드시 폐기해야 한다.

첫 번째 및 마지막 서브넷 주소

[편집]

모든 서브넷에서 모두 0인 호스트 주소와 모두 1인 호스트 주소는 모두 예약되어 있다.[25][26] 모두 0인 호스트 주소는 주어진 서브넷을 식별하는 데 사용된다. 모든 호스트 비트가 1로 설정된 각 서브넷의 가장 높은 주소는 서브넷의 모든 장치에 동시에 메시지를 보내기 위한 로컬 브로드캐스트 주소이다. 크기가 /24 이상인 네트워크의 경우, 점-십진 표기법의 브로드캐스트 주소는 항상 255로 끝난다.

예를 들어, 서브넷 192.168.5.0/24(서브넷 마스크 255.255.255.0)에서 식별자 192.168.5.0은 전체 서브넷을 지칭하는 데 사용된다. 네트워크의 브로드캐스트 주소는 192.168.5.255이다.

유형이진 형식점-십진 표기법
네트워크 공간 11000000.10101000.00000101.00000000 192.168.5.0
브로드캐스트 주소 11000000.10101000.00000101.11111111 192.168.5.255
빨간색은 IP 주소의 호스트 부분을 나타내며, 다른 부분은 네트워크 접두사이다. 호스트 부분은 반전(논리 NOT)되지만 네트워크 접두사는 그대로 유지된다.

그러나 이것이 0 또는 255로 끝나는 모든 주소를 호스트 주소로 사용할 수 없음을 의미하지는 않는다. 예를 들어, 주소 범위 192.168.0.0–192.168.255.255와 동일한 /16 서브넷 192.168.0.0/255.255.0.0에서 브로드캐스트 주소는 192.168.255.255이다. 255로 끝나더라도 192.168.1.255, 192.168.2.255 등의 주소를 호스트용으로 사용할 수 있다. 또한 192.168.0.0은 네트워크 식별자이며 인터페이스에 할당해서는 안 된다.[27](p. 31) 192.168.1.0, 192.168.2.0 등의 주소는 0으로 끝나더라도 할당될 수 있다.

과거에는 일부 소프트웨어가 1 대신 0을 사용하는 비표준 브로드캐스트 주소를 사용하여 네트워크 주소와 브로드캐스트 주소 간의 충돌이 발생하기도 했다.[27](p. 66)

/24보다 작은 네트워크에서 브로드캐스트 주소가 반드시 255로 끝나는 것은 아니다. 예를 들어, CIDR 서브넷 203.0.113.16/28의 브로드캐스트 주소는 203.0.113.31이다.

유형이진 형식점-십진 표기법
네트워크 공간 11001011.00000000.01110001.00010000 203.0.113.16
브로드캐스트 주소 11001011.00000000.01110001.00011111 203.0.113.31
빨간색은 IP 주소의 호스트 부분을 나타내며, 다른 부분은 네트워크 접두사이다. 호스트 부분은 반전(논리 NOT)되지만 네트워크 접두사는 그대로 유지된다.

특수한 경우로, /31 네트워크는 단 두 개의 호스트를 위한 용량을 가진다. 이러한 네트워크는 일반적으로 점대점 연결에 사용된다. 이 네트워크들에는 네트워크 식별자나 브로드캐스트 주소가 없다.[28]

주소 확인

[편집]

인터넷상의 호스트는 보통 라우팅 및 네트워크 인터페이스 식별에 사용되는 IP 주소보다는 www.example.com과 같은 이름으로 알려져 있다. 도메인 이름을 사용하려면 이를 주소로 번역(확인)하거나 그 반대로 번역해야 한다. 이는 수신자의 이름을 사용하여 전화번호부에서 전화번호를 찾는 것과 유사하다.

주소와 도메인 이름 간의 번역은 도메인 네임 시스템(DNS)에 의해 수행되는데, 이는 이름공간의 하위 위임을 다른 DNS 서버에 허용하는 계층적이고 분산된 명명 시스템이다.

번호 없는 인터페이스

[편집]

전송 링크라고도 불리는 번호 없는 점대점(PtP) 링크는 IP 네트워크 또는 서브넷 번호가 할당되어 있지 않지만 여전히 IP 주소를 갖는 링크이다. 1993년에 처음 도입되었으며,[29][30][31][32] 퀄컴의 필 칸(Phil Karn)이 최초 설계자로 알려져 있다.

전송 링크의 목적은 데이터그램을 라우팅하는 것이다. 이들은 희소한 IP 주소 공간에서 IP 주소를 아끼거나, IP 할당 관리 및 인터페이스 구성을 줄이기 위해 사용된다. 이전에는 모든 링크가 점대점 링크당 2개 또는 4개의 IP 주소를 사용하는 /31 또는 /30 서브넷을 전용으로 할당해야 했다. 링크에 번호가 없는 경우, 정의된(보통 루프백) 인터페이스에서 빌려온 단일 IP 주소인 router-id가 사용된다. 동일한 router-id를 여러 인터페이스에서 사용할 수 있다.

번호 없는 인터페이스의 단점 중 하나는 원격 테스트 및 관리가 더 어렵다는 것이다.

패킷 구조

[편집]

IP 패킷은 헤더 섹션과 데이터 섹션으로 구성된다. IP 패킷은 데이터 섹션 뒤에 데이터 체크섬이나 다른 푸터가 없다. 일반적으로 링크 계층은 대부분의 오류를 감지하는 CRC 푸터가 포함된 프레임에 IP 패킷을 캡슐화한다. IP에 의해 운반되는 많은 전송 계층 프로토콜들도 자체적인 오류 검사 기능을 가지고 있다.[33](§6.2)

헤더

[편집]

IPv4 패킷 헤더는 14개의 필드로 구성되며, 그중 13개는 필수 항목이다. 14번째 필드는 선택 사항이며 적절하게 옵션(options)이라는 이름이 붙여졌다. 헤더의 필드들은 최상위 바이트가 먼저 오도록 채워지며(네트워크 바이트 순서), 도식 및 논의를 위해 최상위 비트가 먼저 오는 것으로 간주한다(MSB 0 비트 번호 지정). 최상위 비트는 0번으로 번호가 매겨지므로, 예를 들어 버전 필드는 실제 첫 번째 바이트의 상위 4개 비트에서 발견된다.

IPv4 헤더 형식
오프셋 옥텟 0 1 2 3
옥텟 비트 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 버전 (4) IHL DSCP ECN 총 길이
4 32 식별 플래그 단편 오프셋
8 64 타임 투 리브 프로토콜 헤더 체크섬
12 96 소스 주소
16 128 목적지 주소
20 160 (옵션) (IHL > 5인 경우)
⋮ ⋮
56 448
버전: 4 비트:IP 패킷의 첫 번째 헤더 필드는 버전 필드이다. IPv4의 경우, 이는 항상 4와 같다.
인터넷 헤더 길이 (IHL): 4 비트:IPv4 헤더는 선택 사항인 14번째 필드(옵션)로 인해 크기가 가변적이다. IHL 필드는 IPv4 헤더의 크기를 포함하며, 헤더에 있는 32비트 워드의 수를 지정하는 4비트로 구성된다. 이 필드의 최소값은 5이며,[34] 이는 5 × 32비트 = 160비트 = 20바이트의 길이를 나타낸다. 4비트 필드로서 최대값은 15이며, 이는 IPv4 헤더의 최대 크기가 15 × 32비트 = 480비트 = 60바이트임을 의미한다.
차등 서비스 코드 포인트 (DSCP): 6 비트:원래 서비스 유형(ToS)으로 정의되었던 이 필드는 차등화 서비스(DiffServ)를 지정한다.[35] 실시간 데이터 스트리밍은 DSCP 필드를 활용한다. 예로는 대화형 음성 서비스에 사용되는 음성 인터넷 프로토콜(VoIP)이 있다.
명시적 혼잡 알림 (ECN): 2 비트:이 필드는 패킷을 버리지 않고 네트워크 혼잡의 엔드 투 엔드 알림을 가능하게 한다.[36] ECN은 양쪽 끝점이 이를 지원할 때 사용할 수 있는 선택적 기능이며, 하부 네트워크에서도 지원될 때 효과적이다.
총 길이: 16 비트:이 16비트 필드는 헤더와 데이터를 포함한 전체 패킷 크기를 바이트 단위로 정의한다. 최소 크기는 20바이트(데이터 없는 헤더)이고 최대 크기는 65,535바이트이다. 모든 호스트는 최대 576바이트 크기의 데이터그램을 재조합할 수 있어야 하지만, 대부분의 현대 호스트는 훨씬 더 큰 패킷을 처리한다. 링크가 패킷 크기에 추가 제한을 둘 수 있으며, 이 경우 데이터그램은 IP 단편화되어야 한다. IPv4에서의 단편화는 송신 호스트 또는 라우터에서 수행된다. 재조합은 수신 호스트에서 수행된다.
식별: 16 비트:이 필드는 식별 필드이며 주로 단일 IP 데이터그램의 단편 그룹을 고유하게 식별하는 데 사용된다. 일부 실험적인 작업에서는 위조된 소스 주소를 가진 데이터그램을 추적하는 데 도움이 되는 패킷 추적 정보를 추가하는 것과 같은 다른 목적으로 ID 필드를 사용하는 것을 제안했지만,[37] 현재 그러한 사용은 금지되어 있다.[38]
플래그: 3 비트:이 필드 내에는 세 개의 플래그가 정의되어 있다.
예약됨 (R): 1 비트:예약됨. 0으로 설정되어야 한다.[a]
단편화 방지 (DF): 1 비트:이 필드는 데이터그램의 단편화 가능 여부를 지정한다. 단편의 재조합을 수행할 자원이 없는 호스트로 패킷을 보낼 때 사용할 수 있다. 또한 호스트 IP 소프트웨어에 의해 자동으로, 또는 ping이나 Traceroute와 같은 진단 도구를 사용하여 수동으로 경로 MTU 탐색을 위해 사용될 수 있다. DF 플래그가 설정되어 있는데 패킷 라우팅을 위해 단편화가 필요한 경우, 패킷은 폐기된다.
추가 단편 (MF): 1 비트:단편화되지 않은 패킷의 경우 MF 플래그가 해제된다. 단편화된 패킷의 경우 마지막 단편을 제외한 모든 단편에 MF 플래그가 설정된다. 마지막 단편은 0이 아닌 단편 오프셋 필드를 가지므로 단편화되지 않은 패킷과 여전히 구별될 수 있다.
단편 오프셋: 13 비트:이 필드는 원래의 단편화되지 않은 IP 데이터그램의 시작 부분에 대한 특정 단편의 오프셋을 지정한다. 단편은 8바이트 단위로 지정되며, 이것이 마지막 단편을 제외한 단편의 길이가 항상 8의 배수인 이유이다.[40]
첫 번째 단편의 단편화 오프셋 값은 항상 0이다. 필드 너비는 13비트이므로 오프셋 값의 범위는 0에서 8191((20 – 1)에서 (213 – 1))까지이다. 따라서 헤더 길이를 포함하여 (213 – 1) × 8 = 65,528바이트(65,528 + 20 = 65,548바이트)의 최대 단편 오프셋을 허용하며, 이는 최대 IP 길이인 65,535바이트를 초과하는 패킷의 단편화를 지원한다.
타임 투 리브 (TTL): 8 비트:타임 투 리브 필드는 라우팅 루프 발생 시 네트워크 장애를 방지하기 위해 데이터그램의 수명을 제한한다. 초 단위로 지정되지만, 1초 미만의 시간 간격은 1로 올림된다. 실제로는 홉 수로 사용되며, 데이터그램이 라우터에 도착할 때마다 라우터는 TTL 필드를 1씩 감소시킨다. TTL 필드가 0이 되면 라우터는 패킷을 폐기하고 일반적으로 송신자에게 ICMP 시간 초과 메시지를 보낸다.
Traceroute 프로그램은 조정된 TTL 값을 가진 메시지를 보내고, 이러한 ICMP 시간 초과 메시지를 사용하여 소스에서 목적지까지 패킷이 통과한 라우터를 식별한다.
프로토콜: 8 비트:이 필드는 IP 데이터그램의 데이터 부분에 사용된 전송 계층 프로토콜을 정의한다. IP 프로토콜 번호 목록은 IANA(Internet Assigned Numbers Authority)에서 관리한다.[24]
일반적인 페이로드 프로토콜은 다음과 같다.
프로토콜 번호프로토콜 이름약어
1인터넷 제어 메시지 프로토콜ICMP
2인터넷 그룹 관리 프로토콜IGMP
6전송 제어 프로토콜TCP
17사용자 데이터그램 프로토콜UDP
41IPv6 캡슐화ENCAP
89최단 경로 우선 프로토콜OSPF
132스트림 제어 전송 프로토콜SCTP
헤더 체크섬: 16 비트:IPv4 헤더 체크섬 필드는 헤더의 오류 검사에 사용된다. 패킷을 보내기 전에 체크섬은 헤더에 있는 모든 16비트 워드의 1의 보수 합에 대한 16비트 1의 보수로 계산된다. 이때 계산 중에 0으로 설정되는 헤더 체크섬 필드 자체도 포함된다. 패킷은 결과 값을 포함하는 헤더 체크섬과 함께 전송된다. 패킷이 라우터나 목적지에 도착하면 네트워크 장치는 이제 헤더 체크섬 필드를 포함하여 헤더의 체크섬 값을 재계산한다. 결과는 0이어야 하며, 다른 결과가 나오면 장치는 패킷을 폐기한다.
패킷이 라우터에 도착하면 라우터는 헤더의 TTL 필드를 감소시킨다. 결과적으로 라우터는 패킷을 다시 보내기 전에 새로운 헤더 체크섬을 계산해야 한다.
패킷의 데이터 부분에 있는 오류는 캡슐화된 프로토콜에 의해 별도로 처리된다. UDP와 TCP 모두 데이터에 적용되는 별도의 체크섬을 가지고 있다.
소스 주소: 32 비트:이 필드는 패킷 송신자의 IPv4 주소를 포함한다. 전송 중에 네트워크 주소 변환(NAT)에 의해 변경될 수 있다.
목적지 주소: 32 비트:이 필드는 패킷의 의도된 수신자의 IPv4 주소를 포함한다. 이 또한 NAT의 영향을 받을 수 있다.
목적지에 직접 도달할 수 있는 경우 패킷은 ARP의 도움을 받아 하부 링크 계층에 의해 전달된다. 그렇지 않은 경우 패킷은 라우팅이 필요하며 대신 게이트웨이 주소로 전달된다.
옵션: 0 - 320 비트, 32 비트의 배수로 패딩됨:옵션 필드는 자주 사용되지 않는다. 일부 옵션을 포함하는 패킷은 위험한 것으로 간주되어 일부 라우터에서 차단될 수 있다.[41] IHL 필드의 값은 모든 옵션과 헤더가 32비트 워드의 정수 개수를 포함하도록 보장하는 데 필요한 패딩을 수용할 수 있을 만큼 충분한 추가 32비트 워드를 포함해야 한다. IHL이 5보다 크면(즉, 6에서 15 사이) 옵션 필드가 존재하며 반드시 고려되어야 함을 의미한다. 옵션 목록은 EOOL(End of Options List, 0x00) 옵션으로 종료될 수 있다. 이는 옵션의 끝이 헤더의 끝과 일치하지 않는 경우에만 필요하다.
대부분의 IP 옵션은 패킷이 얼마나 많은 혹은 어떤 중간 장치를 통과해야 하는지에 대한 사양을 포함하므로, IP 옵션은 인터넷 통신에 사용되지 않으며 일부 IP 옵션을 포함하는 IP 패킷은 네트워크 토폴로지나 네트워크 세부 정보를 노출할 수 있으므로 반드시 폐기되어야 한다.[42](§3.13)

단편화 및 재조합

[편집]

인터넷 프로토콜은 네트워크 간의 트래픽을 가능하게 한다. 설계상 다양한 물리적 성질을 가진 네트워크를 수용하며, 링크 계층에서 사용되는 하부 전송 기술로부터 독립적이다. 하드웨어가 다른 네트워크들은 일반적으로 전송 속도뿐만 아니라 최대 전송 단위(MTU)도 다르다. 한 네트워크가 MTU가 더 작은 네트워크로 데이터그램을 전송하고자 할 때, 데이터그램을 단편화할 수 있다. IPv4에서 이 기능은 인터넷 계층에 배치되었으며, 호스트가 이러한 문제에 노출되는 것을 제한하기 위해 IPv4 라우터에서 수행된다.

대조적으로, 차세대 인터넷 프로토콜인 IPv6는 라우터가 단편화를 수행하는 것을 허용하지 않으며, 호스트가 데이터그램을 보내기 전에 경로 MTU 탐색을 수행해야 한다.

단편화

[편집]

라우터가 패킷을 수신하면 목적지 주소를 확인하고 사용할 출력 인터페이스와 해당 인터페이스의 MTU를 결정한다. 패킷 크기가 MTU보다 크고 패킷 헤더의 DF(Don't Fragment) 비트가 0으로 설정되어 있으면 라우터는 패킷을 단편화할 수 있다.

라우터는 패킷을 단편들로 나눈다. 각 단편의 최대 크기는 출력 MTU에서 IP 헤더 크기(최소 20바이트, 최대 60바이트)를 뺀 값이다. 라우터는 각 단편을 자체 패킷에 넣으며, 각 단편 패킷에는 다음과 같은 변경 사항이 적용된다.

  • 총 길이 필드는 단편 크기가 된다.
  • 추가 단편(MF) 플래그는 마지막 단편을 제외한 모든 단편에 대해 설정되며, 마지막 단편은 0으로 설정된다.
  • 단편 오프셋 필드는 원래 데이터 페이로드에서의 단편 오프셋을 기준으로 설정된다. 이는 8바이트 블록 단위로 측정된다.
  • 헤더 체크섬 필드가 재계산된다.

예를 들어, MTU가 1,500바이트이고 헤더 크기가 20바이트인 경우, 단편 오프셋은 의 배수(0, 185, 370, 555, 740 등)가 된다.

한 라우터에서 패킷이 단편화되고, 그 단편들이 다른 라우터에서 추가로 단편화되는 것이 가능하다. 예를 들어, 20바이트 IP 헤더를 포함하여 4,520바이트인 패킷이 MTU가 2,500바이트인 링크에서 두 개의 패킷으로 단편화된다.

단편 크기
(바이트)		 헤더 크기
(바이트)		 데이터 크기
(바이트)		 플래그
추가 단편		 단편 오프셋
(8바이트 블록)
1 2,500 20 2,480 1 0
2 2,040 20 2,020 0 310

전체 데이터 크기는 유지된다: 2,480바이트 + 2,020바이트 = 4,500바이트. 오프셋은 과 이다.

MTU가 1,500바이트인 링크로 전달될 때, 각 단편은 다시 두 개의 단편으로 단편화된다.

단편 크기
(바이트)		 헤더 크기
(바이트)		 데이터 크기
(바이트)		 플래그
추가 단편		 단편 오프셋
(8바이트 블록)
1 1,500 20 1,480 1 0
2 1,020 20 1,000 1 185
3 1,500 20 1,480 1 310
4 560 20 540 0 495

마찬가지로 데이터 크기는 유지된다: 1,480 + 1,000 = 2,480, 그리고 1,480 + 540 = 2,020.

또한 이 경우, MF 비트는 1이 포함된 채로 도착한 모든 단편에 대해 1로 유지되며, 도착하는 마지막 단편에 대해서는 평소와 같이 작동한다. 즉, MF 비트는 마지막 단편에서만 0으로 설정된다. 그리고 물론 식별(Identification) 필드는 모든 재단편화된 단편에서 동일한 값을 계속 가진다. 이러한 방식으로 단편이 다시 단편화되더라도 수신자는 처음에 모두 동일한 패킷에서 시작되었음을 알 수 있다.

마지막 오프셋과 마지막 데이터 크기는 전체 데이터 크기를 계산하는 데 사용된다: .

재조합

[편집]

수신자는 다음 조건 중 하나라도 참이면 패킷이 단편임을 알 수 있다.

  • 추가 단편(MF) 플래그가 설정되어 있다(마지막을 제외한 모든 단편에 해당).
  • 단편 오프셋 필드가 0이 아니다(첫 번째를 제외한 모든 단편에 해당).

수신자는 소스 및 목적지 주소, 프로토콜 ID, 식별 필드를 사용하여 일치하는 단편들을 식별한다. 수신자는 단편 오프셋과 추가 단편 플래그를 모두 사용하여 동일한 ID를 가진 단편들의 데이터를 재조합한다. 수신자가 추가 단편 플래그가 0으로 설정된 마지막 단편을 받으면, 마지막 단편의 오프셋에 8을 곱하고 마지막 단편의 데이터 크기를 더하여 원래 데이터 페이로드의 크기를 계산할 수 있다. 주어진 예에서 이 계산은 바이트였다. 수신자가 모든 단편을 가지면 오프셋에 따라 올바른 순서로 재조합하여 원래의 데이터그램을 형성할 수 있다.

보조 프로토콜

[편집]

IP 주소는 네트워킹 하드웨어와 영구적으로 연결되어 있지 않으며, 실제로 현대의 운영체제에서 네트워크 인터페이스는 여러 개의 IP 주소를 가질 수 있다. 링크상의 목적지 호스트로 IP 패킷을 적절하게 전달하기 위해, 호스트와 라우터는 네트워크 인터페이스의 하드웨어 주소[b]와 IP 주소 간의 연관을 맺기 위한 추가 메커니즘이 필요하다. 주소 결정 프로토콜(ARP)은 IPv4를 위해 이러한 IP 주소 대 하드웨어 주소 번역을 수행한다. 또한 반대 방향의 상관관계가 필요한 경우도 많다. 예를 들어 관리자에 의해 주소가 미리 구성되지 않은 경우, IP 호스트가 부팅되거나 네트워크에 연결될 때 자신의 IP 주소를 결정해야 한다. 이러한 역상관을 위한 프로토콜에는 동적 호스트 구성 프로토콜(DHCP), 부트스트랩 프로토콜(BOOTP) 및 드물게 사용되는 리버스 ARP가 포함된다.

같이 보기

[편집]

각주

[편집]
  1. ↑ “IPv6 – Google”. 《www.google.com》. 2022년 1월 28일에 확인함.
  2. ↑ “BGP Analysis Reports” (미국 영어). 《BGP Reports》. 2013년 1월 9일에 확인함.
  3. ↑ “IANA IPv4 Special-Purpose Address Registry”. 《www.iana.org》. 2022년 1월 28일에 확인함.
  4. 1 2 3 4 5 6 M. Cotton; L. Vegoda; B. Haberman (April 2013). R. Bonica. ed. Special-Purpose IP Address Registries. IETF. ISSN 2070-1721. BCP 153. RFC 6890. https://tools.ietf.org/html/rfc6890. Best Common Practice. Obsoletes RFC 4773, 5156, 5735 and 5736. Updated by RFC 8190.
  5. ↑ Davis, Lidija (2009년 2월 21일). “Vint Cerf - We Still Have 80 Per Cent of the World to Connect”. 《The New York Times》. 2024년 5월 10일에 확인함.
  6. ↑ “A Brief History of IPv4” (영어). 《IPv4 Market Group》. 2020년 8월 19일에 확인함.
  7. ↑ “World 'running out of Internet addresses'”. 2011년 1월 25일에 원본 문서에서 보존된 문서. 2011년 1월 23일에 확인함.
  8. ↑ Smith, Lucie; Lipner, Ian (2011년 2월 3일). “Free Pool of IPv4 Address Space Depleted”. Number Resource Organization. 2011년 2월 3일에 확인함.
  9. ↑ ICANN, nanog mailing list. “Five /8s allocated to RIRs – no unallocated IPv4 unicast /8s remain”.
  10. ↑ Asia-Pacific Network Information Centre (2011년 4월 15일). “APNIC IPv4 Address Pool Reaches Final /8”. 2011년 8월 7일에 원본 문서에서 보존된 문서. 2011년 4월 15일에 확인함.
  11. ↑ S. Deering; R. Hinden (December 1998). Internet Protocol, Version 6 (IPv6) Specification. Network Working Group. RFC 2460. https://tools.ietf.org/html/rfc2460. Obsolete. Obsoleted by RFC 8200. Obsoletes RFC 1883. Updated by RFC 5095, 5722, 5871, 6437, 6564, 6935, 6946, 7045 and 7112.
  12. ↑ R. Fink; R. Hinden (March 2004). 6bone (IPv6 Testing Address Allocation) Phaseout. Network Working Group. RFC 3701. https://tools.ietf.org/html/rfc3701. Informational. Obsoletes RFC 2471.
  13. ↑ 《2016 IEEE International Conference on Emerging Technologies and Innovative Business Practices for the Transformation of Societies (EmergiTech)》. Piscataway, NJ: University of Technology, Mauritius, Institute of Electrical and Electronics Engineers. August 2016. ISBN 9781509007066. OCLC 972636788.
  14. ↑ “Understanding IP Addressing: Everything You Ever Wanted To Know” (PDF). 3Com. 2001년 6월 16일에 원본 문서 (PDF)에서 보존된 문서.
  15. 1 2 3 4 Y. Rekhter; B. Moskowitz; D. Karrenberg; G. J. de Groot; E. Lear (February 1996). Address Allocation for Private Internets. Network Working Group. BCP 5. RFC 1918. https://tools.ietf.org/html/rfc1918. Best Current Practice 5. Obsoletes RFC 1627 and 1597. Updated by RFC 6761.
  16. ↑ J. Weil; V. Kuarsingh; C. Donley; C. Liljenstolpe; M. Azinger (April 2012). IANA-Reserved IPv4 Prefix for Shared Address Space. Internet Engineering Task Force. ISSN 2070-1721. BCP 153. RFC 6598. https://tools.ietf.org/html/rfc6598. Best Current Practice 153. Updates RFC 5735.
  17. ↑ S. Cheshire; B. Aboba; E. Guttman (May 2005). Dynamic Configuration of IPv4 Link-Local Addresses. Network Working Group. RFC 3927. https://tools.ietf.org/html/rfc3927. Proposed Standard.
  18. 1 2 3 J. Arkko; M. Cotton; L. Vegoda (January 2010). IPv4 Address Blocks Reserved for Documentation. Internet Engineering Task Force. ISSN 2070-1721. RFC 5737. https://tools.ietf.org/html/rfc5737. Informational. Updates RFC 1166.
  19. ↑ O. Troan (May 2015). B. Carpenter. ed. Deprecating the Anycast Prefix for 6to4 Relay Routers. Internet Engineering Task Force. BCP 196. RFC 7526. https://tools.ietf.org/html/rfc7526. Best Common Practice. Obsoletes RFC 3068 and 6732.
  20. ↑ C. Huitema (June 2001). An Anycast Prefix for 6to4 Relay Routers. Network Working Group. RFC 3068. https://tools.ietf.org/html/rfc3068. Informational. Obsoleted by RFC 7526.
  21. ↑ S. Bradner; J. McQuaid (March 1999). Benchmarking Methodology for Network Interconnect Devices. Network Working Group. RFC 2544. https://tools.ietf.org/html/rfc2544. Informational. Updated by: RFC 6201 and RFC 6815.
  22. 1 2 M. Cotton; L. Vegoda; D. Meyer (March 2010). IANA Guidelines for IPv4 Multicast Address Assignments. IETF. ISSN 2070-1721. BCP 51. RFC 5771. https://tools.ietf.org/html/rfc5771. Best Current Practice 51. Obsoletes RFC 3138 and 3171. Updates RFC 2780.
  23. ↑ S. Venaas; R. Parekh; G. Van de Velde; T. Chown; M. Eubanks (August 2012). Multicast Addresses for Documentation. Internet Engineering Task Force. ISSN 2070-1721. RFC 6676. https://tools.ietf.org/html/rfc6676. Informational.
  24. 1 2 J. Reynolds, ed. (January 2002). Assigned Numbers: RFC 1700 is Replaced by an On-line Database. Network Working Group. RFC 3232. https://tools.ietf.org/html/rfc3232. Informational. Obsoletes RFC 1700.
  25. ↑ R. Braden, ed. (October 1989). Requirements for Internet Hosts -- Communication Layers. Network Working Group. STD 3. RFC 1122. https://tools.ietf.org/html/rfc1122. Internet Standard 3. Updated by RFC 1349, 4379, 5884, 6093, 6298, 6633, 6864, 8029 and 9293. IP 주소는 <Host-number>, <Network-number>, 또는 <Subnet-number> 필드에 대해 0 또는 -1의 값을 가질 수 없다([특별한 경우] 제외).
  26. ↑ J. Reynolds; J. Postel (October 1984). ASSIGNED NUMBERS. Network Working Group. RFC 923. https://tools.ietf.org/html/rfc923. Obsolete. Obsoleted by RFC 943. Obsoletes RFC 900. 특수 주소: 특정 문맥에서 특정 호스트의 식별자가 아닌 기능적 의미를 가진 고정된 주소를 갖는 것이 유용하다. 그러한 사용이 요구될 때, 주소 0은 "이 네트워크"에서와 같이 "이것"을 의미하는 것으로 해석되어야 한다.
  27. 1 2 R. Braden, ed. (October 1989). Requirements for Internet Hosts -- Communication Layers. Network Working Group. STD 3. RFC 1122. https://tools.ietf.org/html/rfc1122. Internet Standard 3. Updated by RFC 1349, 4379, 5884, 6093, 6298, 6633, 6864, 8029 and 9293.
  28. ↑ A. Retana; R. White; V. Fuller; D. McPherson (December 2000). Using 31-Bit Prefixes on IPv4 Point-to-Point Links. Network Working Group. RFC 3021. https://tools.ietf.org/html/rfc3021. Proposed Standard.
  29. ↑ Almquist, Philip; Kastenholz, Frank (December 1993). 《Towards Requirements for IP Routers》. 《Internet Engineering Task Force》.
  30. ↑ P. Almquist (November 1994). F. Kastenholz. ed. Towards Requirements for IP Routers. Network Working Group. RFC 1716. https://tools.ietf.org/html/rfc1716. Obsolete. Obsoleted by RFC 1812.
  31. ↑ F. Baker, ed. (June 1995). Requirements for IP Version 4 Routers. Network Working Group. RFC 1812. https://tools.ietf.org/html/rfc1812. Proposed Standard. Obsoletes RFC 1716 and 1009. Updated by RFC 2644 and 6633.
  32. ↑ “Understanding and Configuring the ip unnumbered Command” (영어). 《Cisco》. 2021년 11월 25일에 확인함.
  33. ↑ C. Partridge; F. Kastenholz (December 1994). Technical Criteria for Choosing IP The Next Generation (IPng). Network Working Group. RFC 1726. https://tools.ietf.org/html/rfc1726. Informational.
  34. ↑ J. Postel, ed. (September 1981). INTERNET PROTOCOL - DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION. IETF. STD 5. RFC 791. IEN 128, 123, 111, 80, 54, 44, 41, 28, 26. https://tools.ietf.org/html/rfc791. Internet Standard 5. Obsoletes RFC 760. Updated by RFC 1349, 2474 and 6864.
  35. ↑ K. Nichols; S. Blake; F. Baker; D. Black (December 1998). Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. Network Working Group. RFC 2474. https://tools.ietf.org/html/rfc2474. Proposed Standard. Obsoletes RFC 1455 and 1349. Updated by RFC 3168, 3260 and 8436.
  36. ↑ K. Ramakrishnan; S. Floyd; D. Black (September 2001). The Addition of Explicit Congestion Notification (ECN) to IP. Network Working Group. RFC 3168. https://tools.ietf.org/html/rfc3168. Proposed Standard. Obsoletes RFC 2481. Updates RFC 2474, 2401 and 793. Updated by RFC 4301, 6040 and 8311.
  37. ↑ Savage, Stefan (2000). 《Practical network support for IP traceback》. 《ACM SIGCOMM Computer Communication Review》 30. 295–306쪽. doi:10.1145/347057.347560.
  38. ↑ J. Touch (February 2013). Updated Specification of the IPv4 ID Field. IETF. ISSN 2070-1721. RFC 6864. https://tools.ietf.org/html/rfc6864. Proposed Standard. Updates RFC 791, 1122 and 2003.
  39. ↑ S. Bellovin (1 April 2003). The Security Flag in the IPv4 Header. Network Working Group. RFC 3514. https://tools.ietf.org/html/rfc3514. Informational. This is an April Fools' Day Request for Comments.
  40. ↑ Bhardwaj, Rashmi (2020년 6월 4일). “Fragment Offset - IP With Ease” (미국 영어). 《ipwithease.com》. 2022년 11월 21일에 확인함.
  41. ↑ “Cisco unofficial FAQ”. 2012년 5월 10일에 확인함.
  42. ↑ F. Gont (July 2011). Security Assessment of the Internet Protocol Version 4. Internet Engineering Task Force. ISSN 2070-1721. RFC 6274. https://tools.ietf.org/html/rfc6274. Informational.
내용주
  1. ↑ 만우절 농담으로서, RFC 3514에서 "이블 비트(Evil bit)"로 사용하기 위해 제안되었다.[39]
  2. ↑ 이더넷을 포함한 IEEE 802 네트워킹 기술의 경우 하드웨어 주소는 MAC 주소이다.

외부 링크

[편집]
  • 위키미디어 공용에 IPv4 관련 미디어 분류가 있습니다.
대한민국
아시아 지역
  • APNIC: Asia Pacific Network Information Center
북미 지역
  • ARIN: American Registry for Internet Numbers
중남미 지역
  • LACNIC: Latin American and Caribbean Internet Addresses Registry
유럽 지역
  • RIPE: Réseaux IP Européens
원본 주소 "https://ko.wikipedia.org/w/index.php?title=IPv4&oldid=41229091"