IPv4
IPv4프로토콜 스택 | |
![]() IPv4 패킷 | |
목적 | 인터넷 워킹 프로토콜 |
---|---|
개발자 | DARPA |
서론 | 전 ( |
영향받은 | IPv6 |
RFC | 791 |
인터넷 프로토콜 스위트 |
---|
응용 프로그램레이어 |
트랜스포트 레이어 |
인터넷 레이어 |
링크 레이어 |
Internet Protocol version 4(IPv4)는 Internet Protocol(IP)의 네 번째 버전입니다.인터넷 및 기타 패킷 교환 네트워크에서 표준 기반 인터넷 워킹 방법의 핵심 프로토콜 중 하나입니다.IPv4는 1982년 SATNET 및 1983년 1월 ARPANET에 실전 배치한 첫 번째 버전입니다.현재도 [1]대부분의 인터넷트래픽 라우팅에 사용되고 있으며, 그 후속 버전인 Internet Protocol version 6(IPv6)[2]이 현재도 사용되고 있습니다.
IPv4 는, 4,294,967,29632 (2) 의 일의 주소를 제공하는 32 비트주소 공간을 사용하고 있습니다만, 큰 블록은 특수한 네트워크용으로 [3][4]예약되어 있습니다.
역사
인터넷 프로토콜 버전4는 1980년 1월(RFC 760)의 이전의 정의를 대체하는 IETF 간행물 RFC 791(1981년 9월)에 기술되어 있습니다.1982년 3월 미국 국방부는 모든 군용 컴퓨터 네트워킹의 [5]표준으로 인터넷 프로토콜 스위트(TCP/IP)를 결정했다.
목적
인터넷 프로토콜은 Internet Protocol Suite의 인터넷 계층에서 인터넷 작업을 정의하고 사용하도록 설정하는 프로토콜입니다.본질적으로 그것은 인터넷을 형성한다.논리 어드레싱 시스템을 사용하여 루팅을 실행합니다.이것은, 송신원호스트로부터 다른 네트워크상의 목적의 행선지 호스트에 1 홉 가까운 다음의 라우터에 패킷을 전송 하는 것입니다.
IPv4는 connectionless protocol로 best effort 전달 모델에서 동작하며 전달을 보증하지 않으며 적절한 시퀀싱이나 중복 전달 회피도 보장하지 않습니다.데이터 무결성을 포함한 이러한 측면은 전송 제어 프로토콜 (TCP)과 같은 상위 계층 전송 프로토콜에 의해 해결됩니다.
주소 지정
![](http://upload.wikimedia.org/wikipedia/commons/thumb/6/66/IPv4_address_structure_and_writing_systems-en.svg/300px-IPv4_address_structure_and_writing_systems-en.svg.png)
IPv4 에서는, 주소 공간을 4294967296 (2) 주소로 제한하는32 32비트주소가 사용됩니다.
IPv4 에서는, 프라이빗 네트워크(최대 1800만 주소) 및 멀티 캐스트 주소(최대 2억 7000만 주소)용의 특수한 주소 블록이 예약됩니다.
주소 표시
IPv4 주소는, 32 비트의 정수치를 나타내는 임의의 표기로 나타낼 수 있습니다.대부분의 경우 닷 10진 표기로 작성됩니다.도트 10진 표기는 10진수로 표현되며 마침표로 구분된 주소의 4옥텟으로 구성됩니다.
예를 들어, 쿼드 도트 IP 주소 192.0.235는 32비트 10진수 3221226219(16진수 형식: 0xC00002)를 나타냅니다.이비
CIDR 표기법에서는 주소와 라우팅 프레픽스를 콤팩트한 형식으로 조합합니다.이 형식에서는 주소 뒤에 슬래시 문자(/)와 라우팅 프레픽스(서브넷마스크)의 선두1비트의 카운트가 계속됩니다.
클래스 풀 네트워킹이 실행되었을 때 다른 주소 표현이 일반적으로 사용되었습니다.예를 들어 루프백주소 127.0.0.1은 일반적으로 127.1로 쓰입니다.이는 네트워크 마스크용으로8비트와 호스트 번호용으로 24비트를 가진 클래스A 네트워크에 속해 있기 때문입니다.닷이 있는 표기로 주소에 지정된 숫자가 4개 미만일 경우 마지막 값은 주소를 4옥텟으로 입력하기 위해 필요한 바이트 수만큼 정수로 취급됩니다.따라서, 주소 127.65530은, 127.0.255.250 에 상당합니다.
할당
IPv4 의 원래의 설계에서는, IP 주소는 2 개의 부분으로 분할되어 있었습니다.네트워크 ID 는 주소의 최상위 옥텟이었고, 호스트 ID 는 주소의 나머지 부분이었습니다.후자는 휴게소라고도 불렸다.이 구조에서는 최대 256개의 네트워크 식별자를 사용할 수 있으며, 이는 곧 부적절한 것으로 판명되었습니다.
이 제한을 극복하기 위해 1981년에 최상위 주소 옥텟을 재정의하여 네트워크 클래스를 만들었습니다.이것이 나중에 클래스 풀네트워킹이라고 불리게 되었습니다.개정된 제도는 5개의 클래스를 정의했다.클래스 A, B 및 C는 네트워크 식별을 위한 비트 길이가 달랐습니다.주소의 나머지 부분은 네트워크 내의 호스트를 식별하기 위해 이전과 같이 사용되었습니다.클래스마다 필드의 크기가 다르기 때문에 각 네트워크 클래스는 호스트 주소를 지정하는 용량이 다릅니다.호스트 어드레싱을 위한 3개의 클래스 외에 클래스 D는 멀티캐스트어드레싱용으로 정의되어 클래스E는 미래의 어플리케이션용으로 예약되어 있습니다.
기존의 클래스 풀네트워크를 서브넷으로 분할하는 것은 1985년 RFC 950의 발행으로 시작되었습니다.이 분할은 1987년 RFC 1109에서 Variable-Length Subnet Mask(VLSM; 가변길이 서브넷마스크)가 도입됨에 따라 더욱 유연해졌습니다.1993년에, 이 작업에 근거해 RFC 1517은 Classless Inter-Domain Routing(CIDR; 클래스리스 도메인간 라우팅)을 도입했습니다.CIDR은 [6](가장 중요한 것부터의) 비트수를 /24와 같이 나타내, 클래스 베이스의 스킴은 클래스 풀이라고 불리고 있습니다.CIDR은 모든 주소 공간을 재파티셔닝할 수 있도록 설계되어 있어 사용자에게 더 작거나 더 큰 주소 블록을 할당할 수 있습니다.CIDR에 의해 작성된 계층 구조는 Internet Assigned Numbers Authority(IANA; 인터넷 할당 번호국) 및 Regional Internet Registry(RIR; 지역 인터넷레지스트리)에 의해 관리됩니다.각 RIR는 IP 주소 할당에 관한 정보를 제공하는 공개 검색 가능한 WHOIS 데이터베이스를 유지합니다.
특수 용도 주소
Internet Engineering Task Force(IETF; 인터넷 기술 특별 조사위원회)와 IANA는 특수한 [7]목적을 위해 다양한 예약 IP 주소의 일반적인 사용을 제한하고 있습니다.특히 이들 주소는 멀티캐스트트래픽에 사용되며 프라이빗네트워크에서 무제한으로 사용할 수 있는 주소 공간을 제공하기 위해 사용됩니다.
특수 주소 블록 주소 블록 주소 범위 주소 수 범위 묘사 0.0.0.0/8 0.0.0.0–0.255.255.255 16777216 소프트웨어 현재의[8] 네트워크 10.0.0.0/8 10.0.0.0–10.255.255.255 16777216 개인 네트워크 개인 네트워크 [9]내의 로컬 통신에 사용됩니다. 100.64.0.0/10 100.64.0.0–100.127.255.255 4194304 개인 네트워크 캐리어 그레이드 NAT 사용 시 서비스 프로바이더와 서브스크라이버 간의 통신용 공유 주소[10] 공간. 127.0.0.0/8 127.0.0.0–127.255.255.255 16777216 주인 로컬 [8]호스트에 대한 루프백주소에 사용됩니다. 169.254.0.0/16 169.254.0.0–169.254.255.255 65536 서브넷 IP 주소가 지정되어 있지 않은 경우(통상은 DHCP 서버로부터 취득했을 경우 등), 단일 링크상의 2개의 호스트간의 링크[11] 로컬주소에 사용됩니다. 172.16.0.0/12 172.16.0.0–172.31.255.255 1048576 개인 네트워크 개인 네트워크 [9]내의 로컬 통신에 사용됩니다. 192.0.0.0/24 192.0.0.0–192.0.0.255 256 개인 네트워크 IETF 프로토콜 [8]할당 192.0.2.0/24 192.0.2.0–192.0.2.255 256 문서 TEST-NET-1, 문서 및 [12]예로서 할당됩니다. 192.88.99.0/24 192.88.99.0–192.88.99.255 256 인터넷 예약 완료.[13]이전에는 IPv6-to-IPv4 릴레이에[14] 사용(IPv6 주소 블록 2002:/16 포함). 192.168.0.0/16 192.168.0.0–192.168.255.255 65536 개인 네트워크 개인 네트워크 [9]내의 로컬 통신에 사용됩니다. 198.18.0.0/15 198.18.0.0–198.19.255.255 131072 개인 네트워크 2개의 개별 [15]서브넷 간의 네트워크 간 통신 벤치마크테스트에 사용됩니다. 198.51.100.0/24 198.51.100.0–198.51.100.255 256 문서 TEST-NET-2, 문서 및 [12]예로서 할당됩니다. 203.0.113.0/24 203.0.113.0–203.0.113.255 256 문서 TEST-NET-3, 문서 및 [12]예로서 할당. 224.0.0.0/4 224.0.0.0–239.255.255.255 268435456 인터넷 IP 멀티캐스트에 사용되고 있습니다.([16]이전 클래스 D 네트워크) 233.252.0.0/24 233.252.0.0-233.252.0.255 256 문서 MCAST-TEST-NET, 문서 및 [16][17]예로서 할당됩니다. 240.0.0.0/4 240.0.0.0–255.255.255.254 268435455 인터넷 향후 [18]사용을 위해 예약되어 있습니다.(구 클래스E 네트워크) 255.255.255.255/32 255.255.255.255 1개 서브넷 "제한된 브로드캐스트" 수신처 [8][19]주소용으로 예약되어 있습니다.
개인 네트워크
IPv4 에 정의되어 있는 약 40억 개의 주소 중, 3 개의 범위의 약 1800만 개의 주소가 프라이빗 네트워크용으로 예약되어 있습니다.이러한 범위의 패킷주소는 퍼블릭인터넷에서는 라우팅 할 수 없습니다.모든 퍼블릭라우터에 의해 무시됩니다.따라서 프라이빗호스트는 퍼블릭네트워크와 직접 통신할 수 없지만 이를 위해 라우팅 게이트웨이에서 네트워크주소 변환이 필요합니다.
예약된 개인 IPv4 네트워크[9] 범위
이름. CIDR 블록 주소 범위 주소 수 클래스 풀 설명 24비트 블록 10.0.0.0/8 10.0.0.0 – 10.255.255.255 16777216 싱글 클래스 A 20비트 블록 172.16.0.0/12 172.16.0.0 – 172.31.255.255 1048576 16개의 클래스 B 블록의 연속 범위. 16비트 블록 192.168.0.0/16 192.168.0.0 – 192.168.255.255 65536 256개의 클래스 C 블록의 연속 범위.
2개의 프라이빗 네트워크(예를 들어 2개의 브런치사무실)는 퍼블릭인터넷 경유로 직접 상호 운용할 수 없기 때문에, 2개의 네트워크는 Virtual Private Network(VPN; 가상프라이빗 네트워크) 또는 IP 터널을 경유하여 인터넷을 경유하여 브리징해야 합니다.VPN 또는 IP 터널은 패킷(프라이빗 주소를 포함한 헤더를 포함)을 IP 터널 경유하여 전송 중에 패킷에 캡슐화할 필요가 있습니다.퍼블릭 네트워크또, 캡슐화된 패킷은, 데이터의 시큐러티를 확보하기 위해서, 퍼블릭네트워크 경유로 송신되도록 암호화되는 경우가 있습니다.
링크 로컬 어드레싱
RFC 3927에서는 링크 로컬주소 지정을 위한 특별한 주소 블록 169.254.0.0/16이 정의되어 있습니다.이러한 주소는 해당 주소를 사용하는 호스트에 직접 연결된 링크(로컬네트워크 세그먼트 또는 포인트 투 포인트 연결 등)에서만 유효합니다.이러한 주소는 라우팅할 수 없습니다.프라이빗 주소와 같이, 이러한 주소는 인터넷을 통과하는 패킷의 송신원 또는 수신처가 될 수 없습니다.이러한 주소는, 주로 호스트가 DHCP 서버 또는 그 외의 내부 설정 방식으로부터 IP 주소를 취득할 수 없는 경우의 주소 자동 설정(Zeroconf)에 사용됩니다.
주소 블록이 예약되어 있을 때는 주소 자동 설정에 관한 표준이 존재하지 않았습니다.Microsoft는 Automatic Private IP Addressing(APIPA)이라고 불리는 구현을 개발했습니다.이것은 수백만 대의 머신에 도입되어 사실상의 표준이 되었습니다.수년 후인 2005년 5월에 IETF는 RFC 3927에 IPv4 링크 로컬주소의 동적 설정이라는 정식 표준을 정의했습니다.
루프백
클래스 A네트워크 127.0.0.0(계급 없는 네트워크 127.0.0.0/8)루프 백 예약됩니다.그의 소스 주소 이 네트워크에 속한 IP패킷이 호스트 밖에서 나타나야 한다.패킷은은 루프 백 소스 또는 대상 주소non-loopback 인터페이스에 받은 신청은 각하되어야 한다.
첫 번째 및 마지막 서브넷주소
는 서브넷에 첫번째 주소 서브넷 자체 확인하는 데 사용됩니다.이 주소에는 모든 호스트비트는 0.표현의 모호함을 피하기 위해, 이 주소 사용된다.[20]마지막 주소 모든 호스트 1비트 세웠다.그것은 모든 장치에 대한 서브넷에 동시에 메시지를 보내는 데 지역 방송 주소로 사용된다.혹은 더 큰size/24의 네트워크의 경우 방송 주소 항상 255으로 끝나게 된다.
예를 들어, 서브넷에 192.168.5.0/24(서브넷 마스크 255.255.255.0을 입력하)는 식별자 192.168.5.0 전체 서브넷을 가리키는 데 사용된다.네트워크의 방송 주소는 192.168.5.255.
유형 | 두 도막 형식 | Dot-decimal 표기법 |
---|---|---|
네트워크 공간 | 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/255.0에서는 브로드캐스트주소는 192.168.255.255입니다.호스트에는 192.168.1.255, 192.168.2.255 등의 주소를 사용할 수 있습니다.또, 192.168.0.0은 네트워크 ID이므로,[21] 인터페이스에 할당할 수 없습니다.주소 192.168.1.0, 192.168.2.0 등은 0으로 끝나도 할당할 수 있습니다.
과거 일부 소프트웨어에서는 표준 이외의 브로드캐스트주소를 [22]1이 아닌0으로 사용했기 때문에 네트워크주소와 브로드캐스트주소간의 경합이 발생했습니다.
/24보다 작은 네트워크에서는 브로드캐스트주소가 반드시 255로 끝나는 것은 아닙니다.예를 들어 CIDR 서브넷203.0.113.16/28의 브로드캐스트주소는 203.0.113.31 입니다.
유형 | 두 도막 형식 | Dot-decimal 표기법 |
---|---|---|
네트워크 공간 | 11001011.00000000.01110001.00010000 | 203.0.113.16 |
브로드캐스트 어드레스 | 11001011.00000000.01110001.00011111 | 203.0.113.31 |
빨간색은 IP 주소의 호스트 부분을 나타냅니다.다른 부분은 네트워크 프레픽스입니다.호스트는 반전되지만(논리적으로 NOT), 네트워크 프레픽스는 그대로 유지됩니다. |
특별한 경우로 /31 네트워크에는 2개의 호스트만 사용할 수 있는 용량이 있습니다.이러한 네트워크는 일반적으로 포인트 투 포인트 접속에 사용됩니다.이러한 [23]네트워크의 네트워크 ID 또는 브로드캐스트주소는 없습니다.
주소 해결
인터넷상의 호스트는, 주로 라우팅이나 네트워크인터페이스 식별에 사용되는 IP 주소가 아닌, www.example.com등의 이름으로 알려져 있습니다.도메인 이름을 사용하려면 주소로 변환(해결)해야 하며, 그 반대도 마찬가지입니다.이것은, 수신자의 이름을 사용해 전화번호부에서 전화 번호를 검색하는 것과 같습니다.
주소와 도메인 이름 간의 변환은 Domain Name System(DNS; 도메인네임 시스템)에 의해 실행됩니다.Domain Name System(DNS; 도메인네임 시스템)은 계층형 분산형 이름 시스템으로 네임스페이스를 다른 DNS 서버에 서브 위임할 수 있습니다.
언난버드 인터페이스
Unnumbered Point-to-Point(PTP; 번호부 포인트 투 포인트) 링크는 중계 링크라고도 불리며 IP 네트워크 또는 서브넷 번호가 관련지어져 있지 않지만 IP 주소가 있는 링크입니다.1993년에 [24][25][26][27][28]처음 소개된 퀄컴의 필 칸이 오리지널 디자이너로 인정받고 있다.
중계 링크의 목적은 데이터그램을 라우팅하는 것입니다.IP 주소를 희박한 IP 주소 공간으로부터 해방하거나, IP 할당의 관리나 인터페이스의 설정을 경감하기 위해서 사용합니다.이전에는 모든 링크가 포인트 투 포인트링크당 2-4개의 IP 주소를 사용하여 전용/30 또는 31 서브넷에 필요했습니다.링크가 번호부여되지 않은 경우 정의된(통상은 루프백) 인터페이스에서 빌린 단일 IP 주소인 router-id 가 사용됩니다.여러 인터페이스에서 동일한 라우터 ID를 사용할 수 있습니다.
언난버드 인터페이스의 단점 중 하나는 리모트테스트와 관리를 하기 어렵다는 것입니다.
주소 공간 소모
1980년대에, 사용 가능한 IPv4주소의 수영장을 처음 네트워크의 원래 설계에서 예상하지 않은 비율로 급격히 감소시킨 것이 분명해 졌다.[29]해당 주소를 고갈 가속화된 주된 시장 세력들이 늘노트북 컴퓨터 같은 모바일 컴퓨팅 장치,, 개인 휴대 단말기(PDA)및 IP데이터 서비스와 스마트 폰 중고 인터넷 사용자의 급증하는 포함했다.게다가, 초고속 인터넷 액세스 가능 장치에 근거한 것이다.피로의 위협은 바로 같은 치료를 위한 기술에 대한 숫자의 도입 되기도 하였다.
- 작은 인터넷 서비스 공급자 배정을 Classless 의 도메인 간 라우팅(CIDR),.
- Unnumbered 인터페이스, 대중 교통에 링크를 필요성을 제거했다.
- 네트워크 주소 변환, 엔드 투 엔드 원칙의 필요성을 제거했다.
1990년대 중반까지, 네트워크 주소 변환(NAT)광범위하게 네트워크 액세스 공급자 시스템에서, 지방과 지역의 인터넷 레지 스트르라 와에서 엄격한 사용량 기반 분배 정책과 함께 사용되었다.
인터넷의 1차 어드레스 수영장, IANA에 의해 유지되는, 32011년 2월의 마지막 5블록은 5RIRs에 할당되었다..에 지쳐 버렸다.[30][31일]아·태 네트워크 정보 센터 최초의 RIR4월 15일 2011년의 지역적 수영장으로 기진맥진되는 것이, 주소가 작은 공간 전환 기술에 대해 IPv6, 제한된 정책에 따라 할당될 것을 고쳐먹을 빼고[32]
인터넷 프로토콜 IPv6의 새 버전의 장기적인 해결책 소진을 해결하기는 1998년 사양입니다.[33]그것은,라, 264호스트 주소를 최소를 최종 사용자의 큰 하위 네트워크 할당을 제공해 인터넷을 통해 개선된 경로 집합할 수 있는 크게 증가한 주소 공간이 제공된다.그래서IPv4-only 호스트 직접 IPv6-only 호스트 의사 소통할 수 없는 하지만, IPv4직접 IPv6와 상호 운용이 가능하지 않다.그6bone 실험적 네트워크 2004년부터 시작해의 폐기로 IPv6의 영구적인 공식적인 구축 2006년 시작했다.[34]IPv6배치의 완공이 중간 전환 기술 호스트들은 인터넷에서 프로토콜의 두 버전을 사용하여 참여할 수 있도록 필요한 상당한 time,[35] 걸릴 것으로 보인다.
패킷 구조
IP 패킷은 헤더 섹션과 데이터 섹션으로 구성됩니다.IP 패킷에는 데이터 섹션 뒤에 데이터 체크섬이나 다른 바닥글이 없습니다.일반적으로 링크 계층은 대부분의 오류를 검출하는 CRC 바닥글을 사용하여 IP 패킷을 프레임에 캡슐화합니다.IP에 의해 전송되는 트랜스포트 계층 프로토콜의 대부분은 자체 오류 검사도 [36]수행합니다.
헤더
IPv4 패킷헤더는 14개의 필드로 구성되어 있으며, 그 중 13개가 필요합니다.14번째 필드는 옵션이며 적절한 이름: options입니다.헤더의 필드는 최상위 바이트 우선(빅엔디안)으로 채워져 있으며 다이어그램과 설명에서는 최상위 비트가 우선(MSB 0 비트 번호부여)으로 간주됩니다.최상위 비트의 번호는 0이므로 버전필드는 예를 들어 첫 번째 바이트의 최상위4비트로 표시됩니다.
오프셋 | 옥텟 | 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 | 버전 | IHL | DSCP | ECN | 총 길이 | |||||||||||||||||||||||||||
4 | 32 | 신분증 | 플래그 | 프래그먼트 오프셋 | |||||||||||||||||||||||||||||
8 | 64 | 존속 가능 시간 | 프로토콜 | 헤더 체크섬 | |||||||||||||||||||||||||||||
12 | 96 | 송신원 IP 주소 | |||||||||||||||||||||||||||||||
16 | 128 | 수신처 IP 주소 | |||||||||||||||||||||||||||||||
20 | 160 | 옵션(IHL > 5인 경우) | |||||||||||||||||||||||||||||||
⋮ | ⋮ | ||||||||||||||||||||||||||||||||
56 | 448 |
- 버전
- IP 패킷의 첫 번째 헤더필드는 4비트버전 필드입니다IPv4 의 경우, 이것은 항상 4 와 같습니다.
- 인터넷 헤더 길이(IHL)
- IPv4 헤더의 사이즈는 옵션의 14번째 필드(옵션)에 의해 가변적입니다.IHL 필드에는 IPv4 헤더의 크기가 포함됩니다.이 필드에는 헤더 내의 32비트 워드 수를 지정하는4비트가 있습니다.이 필드의 최소값은 [37]5로, 5 × 32 비트 = 160 비트 = 20 바이트의 길이를 나타냅니다.4비트 필드로서 최대치는 15입니다.즉, IPv4 헤더의 최대 사이즈는 15 × 32 비트= 480 비트= 60 바이트입니다.
- Differentiated Services Code Point(DSCP; Diff Serv 코드 포인트)
- 이 필드는 원래 Type of Service(ToS; 유형 오브서비스)로 정의되어 있으며 RFC 2474에 [a]따라 Diff Serv(Diff Serv)를 지정합니다.실시간 데이터 스트리밍에서는 DSCP 필드를 사용합니다.예를 들어 대화형 음성 서비스에 사용되는 Voice over IP(VoIP)가 있습니다.
- 명시적 폭주 통지(ECN)
- 이 필드는 RFC 3168에 정의되어 있으며 패킷을 폐기하지 않고 네트워크 폭주를 엔드 투 엔드로 통지할 수 있습니다.ECN은 양쪽 엔드포인트가 ECN을 지원할 때 사용할 수 있는 옵션 기능입니다.또, 기반이 되는 네트워크에서도 서포트되고 있는 경우에 유효합니다.
- 총 길이
- 이 16비트 필드에서는 헤더와 데이터를 포함한 전체 패킷사이즈를 바이트 단위로 정의합니다.최소 사이즈는 20바이트(데이터가 없는 헤더)이고 최대 사이즈는 65,535바이트입니다.모든 호스트는 최대 576바이트 크기의 데이터그램을 재구성할 수 있어야 하지만 대부분의 최신 호스트는 훨씬 더 큰 패킷을 처리합니다.링크는 패킷크기에 더 많은 제한을 가할 수 있습니다.이 경우 데이터그램을 fragment화해야 합니다.IPv4 의 플래그멘테이션은, 송신측 호스트 또는 라우터의 어느 쪽인가로 실행됩니다.재조립은 수신 호스트에서 수행됩니다.
- 신분증
- 이 필드는 식별 필드이며 주로 단일 IP 데이터그램의 fragment 그룹을 일의로 식별하기 위해 사용됩니다.일부 실험적인 작업에서는 [38]스푸핑된 송신원주소를 가진 데이터 그램을 추적하기 위한 패킷트레이싱 정보 추가 등 ID 필드를 다른 목적으로 사용할 것을 권장하고 있습니다만, RFC 6864에서는 이러한 사용을 금지하고 있습니다.
- 플래그
- 이어서 3비트 필드가 나타나 fragment를 제어 또는 식별하기 위해 사용됩니다.이들은 (가장 유의한 것부터 가장 유의하지 않은 것까지 순서대로) 다음과 같습니다.
- 비트 0: 예약됨.[b] 0이어야 합니다.
- 비트 1: Don't Fragment(DF)
- 비트 2: 추가 플래그먼트(MF)
- DF 플래그가 설정되어 있어 패킷 라우팅에 플래그멘테이션이 필요한 경우 패킷은 폐기됩니다.이것은, fragment의 재구성을 실행할 리소스가 없는 호스트에 패킷을 송신할 경우에 사용할 수 있습니다.또한 호스트 IP 소프트웨어에 의해 자동으로 또는 ping이나 traceroute 등의 진단 도구를 사용하여 수동으로 경로 MTU 디스커버리에도 사용할 수 있습니다.
- fragment화되지 않은 패킷의 경우 MF 플래그는 클리어 됩니다.fragment화된 패킷의 경우 마지막 fragment를 제외한 모든 fragment에 MF 플래그가 설정됩니다.마지막 fragment에는 fragment화되지 않은 패킷과 구별되는0 이외의 fragment offset 필드가 있습니다.
- 프래그먼트오프셋
- 이 필드에서는 원래 fragment화되지 않은IP 데이터그램의 선두에 상대적인 특정 fragment의 오프셋을 8바이트 블록 단위로 지정합니다.첫 번째 fragment의 오프셋은 0입니다.13 비트 필드에서는 최대 오프셋(2 – 113) × 8 = 65,528 바이트를 사용할 수 있습니다.이것에 의해, 헤더 길이(65,528 + 20 = 65,548 바이트)를 포함하면, 최대 IP 길이 65,535 바이트를 넘는 패킷의 fragment화가 서포트됩니다.
- 존속가능시간(TTL)
- 8비트 존속 가능 시간 필드는 라우팅 루프 발생 시 네트워크 장애를 방지하기 위해 데이터그램의 수명을 제한합니다.초 단위로 지정되지만 1초 미만의 시간 간격은 1로 반올림됩니다.실제로는 필드는 홉카운트로 사용됩니다.데이터그램이 라우터에 도착하면 라우터는 TTL 필드를 1개씩 줄입니다.TTL 필드가 제로가 되면 라우터는 패킷을 폐기하고 일반적으로 ICMP time exceeded 메시지를 발신인에게 보냅니다.
- 프로그램 traceroute는 조정된TTL 값을 가진 메시지를 발송하고 이러한 ICMP time exceed 메시지를 사용하여 발신기지에서 수신처로 패킷이 통과하는 라우터를 식별합니다.
- 프로토콜
- 이 필드는 IP 데이터그램의 데이터 부분에서 사용되는 프로토콜을 정의합니다.IANA는 RFC 790의 지시에 따라 IP 프로토콜 번호 목록을 유지합니다.
- 헤더 체크섬
- 16비트 IPv4 헤더체크섬필드는 헤더의 에러 체크에 사용됩니다.패킷이 라우터에 도착하면 라우터는 헤더의 체크섬을 계산하여 체크섬필드와 비교합니다.값이 일치하지 않으면 라우터는 패킷을 폐기합니다.데이터 필드의 오류는 캡슐화된 프로토콜로 처리해야 합니다.UDP와 TCP 모두 데이터에 적용되는 별도의 체크섬이 있습니다.
- 패킷이 라우터에 도착하면 라우터는 헤더 내의 TTL 필드를 줄입니다.따라서 라우터는 새로운 헤더체크섬을 계산해야 합니다
- 송신원주소
- 이 필드는 패킷 송신자의 IPv4 주소입니다.이 주소는 네트워크주소 변환 디바이스에 의해 전송 중에 변경될 수 있습니다.
- 수신처 주소
- 이 필드는 패킷 수신자의 IPv4 주소입니다.송신원주소와 같이, 이것은 네트워크주소 변환 디바이스에 의해서 전송중에 변경될 수 있습니다.
- 옵션들
- 옵션 필드는 자주 사용되지 않습니다.일부 옵션을 포함하는 패킷은 일부 라우터에 의해 위험하다고 간주되어 [39]차단될 수 있습니다.IHL 필드의 값에는 모든 옵션을 유지할 수 있는 충분한 추가 32비트 워드와 헤더에 32비트 워드의 정수가 포함되도록 하기 위해 필요한 패딩이 포함되어 있어야 합니다.IHL이 5보다 크면(즉, 6에서 15 사이) 옵션 필드가 존재하며 반드시 고려해야 한다는 것을 의미한다.옵션 목록은 EOL(End of Options List, 0x00) 옵션으로 종료할 수 있습니다.옵션의 끝이 헤더의 끝과 일치하지 않는 경우에만 필요합니다.헤더에 넣을 수 있는 옵션은 다음과 같습니다.
들판 크기(비트) 묘사 복사했다 1 fragment화된 패킷의 모든 fragment에 옵션을 카피할 필요가 있는 경우는, 1 로 설정합니다. 옵션 클래스 2 일반 옵션 범주입니다.0은 제어 옵션, 2는 디버깅 및 측정에 사용됩니다. 1과 3은 예약되어 있습니다. 옵션 번호 5 옵션을 지정합니다. 옵션 길이 8 옵션 전체 크기(이 필드 포함)를 나타냅니다.단순 옵션의 경우 이 필드가 존재하지 않을 수 있습니다. 옵션 데이터 변수 옵션 고유의 데이터.단순 옵션의 경우 이 필드가 존재하지 않을 수 있습니다.
- 다음의 표는, IPv4 에 대해서 정의된 옵션을 나타내고 있습니다.[ Option Type ]컬럼은 위와 [40]같이 [Copyed], [Option Class] 및 [Option Number]비트에서 파생됩니다.
옵션 유형(10진수/16진수) 옵션명 묘사 0/0x00 이울 옵션 리스트의 종료 1/0x01 NOP 동작 없음 02년 2월 초 보안(소실) 07년 7월 RR 루트 기록 10/0x0A ZU 실험 측정 11/0x0B MTUP MTU 프로브 12/0x0C 멀티 MTU 응답 15/0x0F 부호화 부호화 0/25 x 19 QS 퀵 스타트 30/0x1E EXP RFC3692 스타일의 실험 68/0x44 TS 타임스탬프 82/0x52 TR traceroute 94/0x5E EXP RFC3692 스타일의 실험 130/0x82 초 보안(RIPSO) 131/0x83 LSR 루즈 소스 루트 133/0x85 E-SEC 확장 보안(RIPSO) 134/0x86 CIPSO 상용 IP 보안 옵션 136/0x88 SID 스트림 ID 137/0x89 SSR 완전 소스 루트 142/0x8E 비자 Experimental Access Control (Experimental Access Control) 144/0x90 IMITD IMI 트래픽 기술자 145/0x91 EIP 확장 인터넷 프로토콜 147/0x93 ADDEXT 어드레스 내선번호 148/0x94 RTRART 라우터 경보 149/0x95 SDB 선택적 다이렉트 브로드캐스트 151/0x97 DPS 다이내믹 패킷스테이트 152/0x98 UMP 업스트림 멀티캐스트패킷 158/0x9E EXP RFC3692 스타일의 실험 205/0xCD 핀 실험 흐름 제어 222/0xDE EXP RFC3692 스타일의 실험
데이터.
패킷 payload는 체크섬에 포함되지 않습니다.이 내용은 Protocol 헤더 필드의 값을 기반으로 해석됩니다.
IP 프로토콜 번호 목록에는 페이로드 프로토콜 유형의 전체 목록이 포함됩니다.일반적인 페이로드 프로토콜에는 다음이 포함됩니다.
프로토콜 번호 | 프로토콜 이름 | 줄임말 |
---|---|---|
1 | 인터넷 제어 메시지 프로토콜 | ICMP |
2 | 인터넷 그룹 관리 프로토콜 | IGMP |
6 | 전송 제어 프로토콜 | TCP |
17 | 사용자 데이터그램 프로토콜 | UDP |
41 | IPv6 캡슐화 | 엔캡 |
89 | 최단 경로 먼저 열기 | OSPF |
132 | 스트림 제어 전송 프로토콜 | SCTP |
플래그멘테이션 및 재구성
인터넷 프로토콜은 네트워크 간의 트래픽을 활성화합니다.이 설계는 다양한 물리적 성질의 네트워크를 수용합니다.링크 계층에서 사용되는 기본 전송 기술과는 무관합니다.하드웨어가 다른 네트워크는 보통 전송 속도뿐만 아니라 Maximum Transmission Unit(MTU; 최대 전송 유닛)도 다릅니다.1개의 네트워크가 MTU가 작은 네트워크에 데이터그램을 송신하는 경우, 그 데이터그램을 fragment화할 수 있습니다.IPv4 에서는, 이 기능은 인터넷 레이어에 배치되어 IPv4 라우터에서 실행되어 호스트에 의한 이러한 문제에의 노출을 제한합니다.
반면, 차세대 인터넷 프로토콜인 IPv6에서는 라우터의 플래그멘테이션 실행이 허용되지 않습니다.호스트는 데이터그램을 송신하기 전에 패스 MTU 디스커버리를 실행할 필요가 있습니다.
단편화
라우터는 패킷을 수신하면, 행선지 주소를 조사해 사용하는 발신 인터페이스와 그 인터페이스의 MTU 를 결정합니다.패킷 사이즈가 MTU 보다 크고, 패킷헤더의 Do Not Fragment(DF) 비트가 0 으로 설정되어 있는 경우, 라우터는 패킷을 fragment화할 수 있습니다.
라우터는 패킷을 fragment로 분할합니다.각 fragment의 최대 사이즈는 발신 MTU에서 IP 헤더사이즈(최소 20바이트, 최대 60바이트)를 뺀 값입니다.라우터는 각 fragment를 자신의 패킷에 넣습니다.각 fragment 패킷은 다음과 같이 변경됩니다.
- total length 필드는 fragment 크기입니다.
- 마지막 fragment를 제외한 모든 fragment에 대해 more fragments(MF; 더 많은 fragment) 플래그가 0으로 설정됩니다.
- fragment offset 필드는 원래 데이터 페이로드의 fragment 오프셋에 따라 설정됩니다.이것은 8바이트 블록 단위로 측정됩니다.
- 헤더 체크섬필드가 재계산됩니다.
예를 들어 MTU가 1,이고 헤더 크기가 20바이트인 경우 fragment 오프셋은 1,500 8 {\{ - {8} }(0, 185, 370, 555, 740 등)의 배수가 됩니다.
패킷이 1대의 라우터에서 fragment화되어 그 fragment가 다른 라우터에서 한층 더 fragment화되어 있을 가능성이 있습니다.예를 들어, 20 바이트의 IP 헤더를 포함한 4,520 바이트의 패킷은, MTU가 2,500 바이트인 링크상의 2 개의 패킷으로 fragment화 됩니다.
단편화 | 크기 (바이트) | 헤더 사이즈 (바이트) | 데이터 크기 (바이트) | 플래그 기타 fragment | 프래그먼트오프셋 (8바이트 블록) |
---|---|---|---|---|---|
1 | 2,500 | 20 | 2,480 | 1 | 0 |
2 | 2,040 | 20 | 2,020 | 0 | 310 |
총 데이터 크기는 2,540 바이트 + 2,020 바이트 = 4,500 바이트로 유지됩니다.은 0 0 0+, 310({})=입니다.
MTU가 1,500바이트인 링크로 전송되면 각 fragment는 2개의 fragment로 분할됩니다.
단편화 | 크기 (바이트) | 헤더 사이즈 (바이트) | 데이터 크기 (바이트) | 플래그 기타 fragment | 프래그먼트오프셋 (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,440 + 1,000 = 2,440 및 1,440 + 540 = 2,020으로 유지됩니다.
또한 이 경우 More Fragments 비트는 1이 포함된 모든 fragment에 대해 1로 유지되며, 마지막 fragment에 대해서는 정상적으로 동작합니다.즉, 마지막 fragment에서만 MF 비트가 0으로 설정됩니다.물론 Identification 필드는 다시 플래그먼트화된 모든 fragment에서 동일한 값을 유지합니다.이렇게 하면, fragment가 재플래그 되어도, 수신자는, 처음에 모두 같은 패킷으로부터 개시된 것을 인식합니다.
마지막 오프셋과 마지막 데이터 크기는 총 데이터 크기를 계산하는 데 사용됩니다. + { \8 + ={ , + =4 { ,
재조립
다음 조건 중 적어도1개가 충족되면 수신자는 패킷이 fragment임을 인식합니다.
- fragment의 수가 증가하면 fragment가 설정됩니다.이것은 마지막 fragment를 제외한 모든 fragment에 적용됩니다.
- 필드 프래그먼트오프셋은 0이 아닙니다.이것은 첫 번째 fragment를 제외한 모든 fragment에 적용됩니다.
수신자는, 송신원주소와 행선지 주소, 프로토콜 ID, 및 식별 필드를 사용해 일치하는 fragment를 식별합니다.수신기는 fragment offset 및 more fragments 플래그를 모두 사용하여 동일한 ID의 fragment에서 데이터를 재구성합니다.수신기는 fragment 플래그가 0으로 설정된 마지막 fragment를 수신하면 마지막 fragment의 오프셋에 8을 곱하고 마지막 fragment의 데이터 크기를 추가하여 원래 데이터 payload의 크기를 계산할 수 있습니다.의 예에서 이 계산은 × 8 + 4, { \ 8=바이트였습니다.리시버가 모든 fragment를 가지고 있는 경우는, 오프셋에 따라서 올바른 순서로 재구성해 원래의 데이터 그램을 형성할 수 있습니다.
보조 프로토콜
IP 주소는, 네트워크 하드웨어에 영속적으로 관련지어져 있지 않습니다.현대의 operating system에서는, 네트워크 인터페이스에 복수의 IP 주소를 설정할 수 있습니다.IP 패킷을 링크상의 행선지 호스트에 올바르게 전달하려면 , 네트워크인터페이스의[c] 하드웨어 주소와 IP 주소의 어소시에이션을 확립하는 추가 메카니즘이 필요합니다.Address Resolution Protocol(ARP)은, IPv4 의 IP 주소로부터 하드웨어 주소로의 변환을 실행합니다.또한 대부분의 경우 역상관관계가 필요합니다.예를 들어, 관리자가 주소를 미리 설정하지 않는 한, IP 호스트를 기동하거나 네트워크에 접속할 때는, IP 주소를 확인할 필요가 있습니다.이러한 역상관 프로토콜에는 DHCP(Dynamic Host Configuration Protocol), Bootstrap Protocol(BOOTP) 및 드물게 역ARP가 포함됩니다.
「 」를 참조해 주세요.
메모들
레퍼런스
- ^ "BGP Analysis Reports". Retrieved 2013-01-09.
- ^ "IPv6 – Google". www.google.com. Retrieved 2022-01-28.
- ^ "IANA IPv4 Special-Purpose Address Registry". www.iana.org. Retrieved 2022-01-28.
- ^ "RFC 5735 - Special Use IPv4 Addresses". datatracker.ietf.org. Retrieved 2022-01-28.
- ^ "A Brief History of IPv4". IPv4 Market Group. Retrieved 2020-08-19.
- ^ "Understanding IP Addressing: Everything You Ever Wanted To Know" (PDF). 3Com. Archived from the original (PDF) on June 16, 2001.
- ^ Cotton, M.; Vegoda, L. (January 2010). Special Use IPv4 Addresses. doi:10.17487/RFC5735. RFC 5735.
- ^ a b c d M. Cotton; L. Vegoda; R. Bonica; B. Haberman (April 2013). Special-Purpose IP Address Registries. Internet Engineering Task Force. doi:10.17487/RFC6890. BCP 153. RFC 6890. RFC 8190에 의해 갱신되었습니다.
- ^ a b c d Y. Rekhter; B. Moskowitz; D. Karrenberg; G. J. de Groot; E. Lear (February 1996). Address Allocation for Private Internets. Network Working Group. doi:10.17487/RFC1918. BCP 5. RFC 1918. RFC 6761에 의해 갱신되었습니다.
- ^ J. Weil; V. Kuarsingh; C. Donley; C. Liljenstolpe; M. Azinger (April 2012). IANA-Reserved IPv4 Prefix for Shared Address Space. Internet Engineering Task Force (IETF). doi:10.17487/RFC6598. ISSN 2070-1721. BCP 153. RFC 6598.
- ^ S. Cheshire; B. Aboba; E. Guttman (May 2005). Dynamic Configuration of IPv4 Link-Local Addresses. Network Working Group. doi:10.17487/RFC3927. RFC 3927.
- ^ a b c J. Arkko; M. Cotton; L. Vegoda (January 2010). IPv4 Address Blocks Reserved for Documentation. Internet Engineering Task Force. doi:10.17487/RFC5737. ISSN 2070-1721. RFC 5737.
- ^ O. Troan (May 2015). B. Carpenter (ed.). Deprecating the Anycast Prefix for 6to4 Relay Routers. Internet Engineering Task Force. doi:10.17487/RFC7526. BCP 196. RFC 7526.
- ^ C. Huitema (June 2001). An Anycast Prefix for 6to4 Relay Routers. Network Working Group. doi:10.17487/RFC3068. RFC 3068. RFC 7526에 의해 폐지되었습니다.
- ^ S. Bradner; J. McQuaid (March 1999). Benchmarking Methodology for Network Interconnect Devices. Network Working Group. doi:10.17487/RFC2544. RFC 2544. 갱신자: RFC 6201 및 RFC 6815
- ^ a b M. Cotton; L. Vegoda; D. Meyer (March 2010). IANA Guidelines for IPv4 Multicast Address Assignments. Internet Engineering Task Force. doi:10.17487/RFC5771. BCP 51. RFC 5771.
- ^ S. Venaas; R. Parekh; G. Van de Velde; T. Chown; M. Eubanks (August 2012). Multicast Addresses for Documentation. Internet Engineering Task Force. doi:10.17487/RFC6676. RFC 6676.
- ^ J. Reynolds, ed. (January 2002). Assigned Numbers: RFC 1700 is Replaced by an On-line Database. Network Working Group. doi:10.17487/RFC3232. RFC 3232. RFC 1700을 폐지합니다.
- ^ Jeffrey Mogul (October 1984). Broadcasting Internet Datagrams. Network Working Group. doi:10.17487/RFC0919. RFC 919.
- ^ "RFC 923". IETF. June 1984. Retrieved 15 November 2019.
Special Addresses: In certain contexts, it is useful to have fixed addresses with functional significance rather than as identifiers of specific hosts. When such usage is called for, the address zero is to be interpreted as meaning "this", as in "this network".
- ^ Robert Braden (October 1989). "Requirements for Internet Hosts – Communication Layers". IETF. p. 31. RFC 1122.
- ^ Robert Braden (October 1989). "Requirements for Internet Hosts – Communication Layers". IETF. p. 66. RFC 1122.
- ^ RFC 3021
- ^ Almquist, Philip; Kastenholz, Frank (November 1994). "Towards Requirements for IP Routers". Internet Engineering Task Force.
- ^ RFC 1916
- ^ RFC 1716
- ^ RFC 1812
- ^ "Understanding and Configuring the ip unnumbered Command". Cisco. Retrieved 2021-11-25.
- ^ "World 'running out of Internet addresses'". Archived from the original on 2011-01-25. Retrieved 2011-01-23.
- ^ Smith, Lucie; Lipner, Ian (3 February 2011). "Free Pool of IPv4 Address Space Depleted". Number Resource Organization. Retrieved 3 February 2011.
- ^ ICANN,nanog mailing list. "Five /8s allocated to RIRs – no unallocated IPv4 unicast /8s remain".
- ^ Asia-Pacific Network Information Centre (15 April 2011). "APNIC IPv4 Address Pool Reaches Final /8". Archived from the original on 7 August 2011. Retrieved 15 April 2011.
- ^ Hinden, Bob; Deering, Steve E. (December 1998). "Internet Protocol, Version 6 (IPv6) Specification". tools.ietf.org. Retrieved 2019-12-13.
- ^ Fink, R.; HInden, R. (March 2004). 6bone (IPv6 Testing Address Allocation) Phaseout. doi:10.17487/RFC3701. RFC 3701.
- ^ 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.
- ^ Partridge, C.; Kastenholz, F. (December 1994). "6.2 IP Header Checksum". Technical Criteria for Choosing IP The Next Generation (IPng). p. 26. sec. 6.2. doi:10.17487/RFC1726. RFC 1726.
- ^ Postel, J. Internet Protocol. doi:10.17487/RFC0791. RFC 791.
- ^ Savage, Stefan (2000). "Practical network support for IP traceback". ACM SIGCOMM Computer Communication Review. 30 (4): 295–306. doi:10.1145/347057.347560. Retrieved 2010-09-06.
- ^ "Cisco unofficial FAQ". Retrieved 2012-05-10.
- ^ "Internet Protocol Version 4 (IPv4) Parameters".
외부 링크
- 인터넷 할당 번호 기관(IANA)
- IP, Internet Protocol - IP 헤더 분석(특정 옵션 포함)
- IP Mobility Support for IPv4. RFC 3344.
- IANA에 의해 유지되는 IPv4/8 할당의 공식 현재 상태