2.IP 프로토콜(인터넷계층, BestEffort, IP패킷구조, IP 주소, IPv6, 특수주소, 메시지 분할 전송, path MTU, DHCP, 고정IP, NAT, 포트번호, ARP/RARP , ICMP, IGMP, 서브네팅,)

인터넷 계층

인터넷 계층은 인터넷 프로토콜(IP)을 수행하는 계층으로 하위(sub) 네트워크에 무관하게 IP 패킷을 호스트(컴퓨터) 사이에 전달하는 기능을 수행한다.
OSI 7 계층 관점에서 보면 인터넷 계층은 주소(addresing)와 교환(Switching) 그리고 라우팅을 담당한다.
IP는 비연결형 서비스로 동작한다. 따라서 IP에서는 각 패킷이 개별적으로 목적지를 찾아갈 수 있어야 하므로 IP 패킷은 송신자와 수신자의 주소로서 각각 32비트의 IP 주소를 항상 포함하고 있어야 한다.
IP프로토콜은 인터넷 계층이라고도 한다. 3계층에 포함된다. 주의해야 할 개념은 교환(Switching)과 라우팅의 개념이 다르다는것이다. 교환(Switching)은 패킷이 들어오면 어디로 나갈지 찾아주는것이고 라우팅은 최종적으로 어디를 거쳐가야 할 지를 알려주는것이다.
비연결형(connectless) 서비스란 연결설정과 종료과정이 따로 없이, 바로 데이터를 송수신하는 통신 방법을 말한다.
연결설정과 종료과정이 항상 필요한 통신 방식은 연결형(connection-oriented)서비스라고 한다.
IP 프로토콜의 핵심은 따로 이 32비트의 IP주소(이를 인터넷 주소라고도 한다.)의 사용인데, IP 주소는 인터넷에 접속된 모든 호스트에 대하여 전세계적으로 유일하게 배정되는 주소이다.(간단하게 컴퓨터를 찾아가는 주소를 의미, 주민등록번호가 2개일수 없듯이 같은 디바이스에 2개의 IP주소는 불가능하다.)

Best effort(한 줄요약: 나는 최선을 다할건데 오류나도 어쩔수 없다.)

IP는 "Best effor로 패킷을 전달"하는데 이것의 의미는 IP는 비연결형으로 패킷을 전달하며 패킷의 분실, 중복 패킷 전달. 패킷 전달 순서의 바뀜, 비트 오류 등이 발생하더라도 IP에서 패킷 재전송이나 오류 확인 등의 기능을 제공하지 않는다는 것을 뜻한다.
즉, IP 계층은 최대한 잘 전달하려고 노력만 할 뿐 전송 결과를 패킷 단위로 확인해주지 않는다.
두 호스트 사이에 패킷이 잘 전달되는지의 확인은 상위 계층인 트랜스포트계층(TCP 또는 UDP)에서 처리된다.

IP 패킷 구조란?

IP 계층에서 다루는 프로토콜 데이터 단위인 IP 패킷의 구조는 다음과 같다.

위의 그림에서 한 줄은 4바이트(32비트) 크기이며 네트워크로 전송될 때에는 상위의 자측 바이트부터 전송된다.
송신자와 수신자를 나타내는 IP 주소는 각각 네 번째와 다섯 번째 줄에 들어가며 상위 계층의 사용자 메시지는 헤더 뒤에 전송된다.
Ver(Version)은 IP프로토콜의 버전을 표시하는데 현재는 4이다.(따라서 현재 사용중인 인터넷 버전을 IPv4라고도 표현한다,)
IHL(Internet Header Length)는 헤더 길이를 4바이트 단위로 표시하는데 디폴트 값은 5이다.(즉, 헤더의 기본 크기는 20바이트가 된다.)
서비스 타입은 응용에 따라 이 IP패킷이 각각 다르게 처리되기를 지정하는 필드이다.
Total Length는 헤더를 포함한 IP 패킷의 전체 크기를 바이트 단위로 나타내는데 Total Length가 16비트 크기이므로 IP 패킷의 최대길이는 65535 바이트까지 표현할 수 있다.
Identification은 수신측에서 패킷을 재조립할 때 사용하는 고유 번호이다.
Flags는 세 비트로 구성되는데, 첫 비트는 사용하지 않으며 항상 0이어야한다. 두 번째 비트는 세분화 금지 플레그 DF이고 세 번째 비트는 More비트인데 아래 그림 참조(이 데이터의 특성을 나타내는것만 기억

TTL(Time To Live)은 패킷이 어떤 오류에 의해서 제대로 목적지에 전달되지 못하고 인터넷 내에서 계속 돌아다니느 것을방지하기 위해서 패킷이 일정시간 동안만 인터넷상에서 전달되도록 제한하려고 정의한 것이다.
즉 중간의 라우터들은 이 TTL 시간 동안만 이 패킷의 전달을 처리해주며 TTL 값은 시간이 지나면서 값이 감소하다가 0이 되면 전달을 중지한다.
그러나 인터넷 전체를 통해 동일한 시계를 운영하는 것이 불편하므로 TTL은 실제로는 시간 대신 hop counter 값으로 사용되고 있다.(hop이란 패킷이 링크를 동해 노드를 하나 지나가는 것을 말한다.)
즉, TTL 값은 패킷이 한 노드를 지나갈 때마다 1씩 감소하고 TTL이 0이 되는 노드에서 이 패킷을 제거함으로써 이 패킷이 더 이상 인터넷창에서 돌아다니지 않도록 한다.
TTL의 초기 값을 어떻게 정해줄지를 정해야 하는데 이것은 목적지까지 패킷이 전달될 동안 거치게 될 총 라우터의 수보다 조금 크게 잡아주면 된다.
TTL 값이 너무 크면 오류가 발생한 경우에 패킷이 네트워크 내에 오래 남아 있게 되어 트래픽이 증가할 수 있고, TTL 값이 너무 적으면 라우팅이 달라져서 패킷이 먼 거리를 돌아가게 되었을 때 목적지에 도착하지 못할 수가 있다.
실제로는 위에처럼 고민하지 않는다. TTL 값을 매 IP 패킷마다 별도로 정해주는 것은 불편하므로 보통 디폴트로 64 값을 사용한다.(세계 어디를 보내도 64번이면 충분하다는 의미)

Protocol은 이 IP 패킷을 전달할 상위 계층 프로토콜을 구분하는데 사용된다. 상위계층 프로토콜이 TCP이면 6, UDP이면 17, ICMP이면 1로 지정된다.(ICMP를 사용한다는것은 데이터를 컨트롤하는 정보가 있다는 의미)
Header CheckSum은 헤더의 오류 검출을 위해 사용되며 헤더를 16비트 단위로 나누어 각각을 숫자로 보고 이를 차례로 더한 값이 된다.
덧셈은 one's complement로 계산하며 수신측에서도 같은 계산을 하여 결과를 비교하여 결과가 다르면 헤더에서 오류가 발생한 것이므로 이 패킷을 버린다.
목적지 주소는 패킷을 전달하기 위해서 필요하며 송신지 주소는 이 패킷을 목적지에서 수신할지를 판단할 때 사용되며 답장을 하기 위해서도 필요하다.
IP Options은 IP 프로토콜의 기본 기능 외에 추가로 세부적인 옵션을 지정할 때 사용되는데 실제로는 거의 사용하지 않는다.
IP 패킷에 옵션이 들어 있는지는 Length 필드의 값을 보고 판단할 수 있다.(즉, Length가 5이면 옵션이 없는 것임을 알 수 있다.)

한줄요약: 단순하게 가자. 몇 비트 바이트 줄일려고 난리 치는 것보다 간편하게 가는게 좋다. 50년째 이어지고 있다.

IP 주소란?

호스트, 라우터 등 인터넷 장비를 구분하기 위해서 4바이트의 IP 주소를 사용한다.
4바이트의 IP 주소를 보기 쉽게 표시하기 위하여 IP 주소를 네 개의 바이트 단위로 나누고 각 바이트의 값을 10진수로 표시하는 dotted decimal표현 방식이 널리 사용되고 있다.
예를 들어 IP 주소 10000001 0001010 0000110 0000111을 dotted decimal IP 주소로 표현하면 129.10.6.7이 된다. 컴퓨터는 10000001 0001010 0000110 0000111 -> 129.10.6.7로 번역해서 알아듣는다. 역 으로도 마찬가지.
IP 주소는 네트워크를 구분하기 위한 netid 필드(허브같은거)와 한 네트워크 내에서 호스트를 구분하기 위한 hostid 필드(허브에 장착되어 있는 랜같은거) 두 부분으로 구성된다.
netid와 hostid에서 각각 사용하는 비트 수의 크기에 따라 여러 가지 클래스의 주소 체계를 가지고 있다(맨 앞 비트 ex:) 0, 10, 110, 1110은 주소 체계의 종류를 의미함 각각 A, B, C, D )

클래스 A주소는 IP 주소 첫 번째 바이트의 첫 비트가 0이고 나머지 7비트가 netid이다
ex:) C는 대학용 D는 카카오톡 단톡방 같은 경우가 대표 사례.
- 0.0.0.0 = A
- 129.0.0.0 = B
- A>129.0.0.0 = C
클래스 A네트워크 개수는 126개가 있다.(netid 부분이 모두 0과 모두 1인 주소는 사용할 수 없으므로 2개를 제외해야한다).
클래스 B주소는 IP 주소 첫 번째 바이트의 처음 두 비트가 10이고 나머지 6비트와 두 번째 바이트가 netid이다. 뒤의 두 바이트가 hostid이므로 하나의 클래스 B주소는 (2^16 - 2)대의 호스트를 수용할 수 있다.
클래스 C주소는 IP 주소 첫 번째 바이트의 처음 세 비트가 110이고 나머지 5비트와 2, 3번째 바이트가 netid이다. 마지막 한 바이트가 hostid이므로 하나의 클래스 C 주소는 254대의 호스트를 수용한다.
클래스 D 주소는 IP 주소 첫 번째 바이트의 처음 네 비트가 1110이다. 이것은 멀티캐스트 주소를 의미한다.

IP 주소 체계의 가장 큰 특징의 IP 주소가 netid(비유: 건물)와 hostid(비유: 건물 방) 두 부분으로 구성되어 있다는 것이다.
IP 주소 체계의 또 다른 특징은 어떤 호스트가 둘 이상의 네트워크에 연결되어 있는 경우 이 호스트는 접속된 네트워크 수만큼 IP 주소를 각각 가지고 있어야 한다는 것이다.
왜냐하면 IP 주소에는 netid 부분이 있으므로 접속된 네트워크 별로 각각 netid가 다르기 때문이다.
이와 같이 둘 이상의 네트워크에 연결되어 다수의 IP 주소를 가지고 있는 호스트를 멀티홈(multi-homed) 호스트라고 한다.(ex:)라우터) 멀티홈 호스트 중요
멀티홈 호스트가 되려면 둘 이상의 LAN 또는 전용선을 통하여 각기 다른 네트워크로 연결되어 있어야 한다.
라우터도 일종의 multi-homed 호스트이므로 라우터는 접속된 각 네트워크의 netid와 같은 netid를 가지는 IP 주소들을 각각 가지고 있어야 한다.

IPv6

4바이트로 구성된 IP 주소를 사용해서는 전 세계의 모든 통신장비에게 고유한 주소를 배정할 수 없다. 이를 해결하기 위해서 주소가 16바이트(128비트)로 구성된 IPv6을 제정하였다.
그러나 IPv6는 실제로 도입되지 않았으며 부족한 주소는 다른 방법으로 해결하였다.

특수 주소

이전에 네트워크 주소 2가지(모두 0, 모두 1)를 사용하지 않는다고 했는데 그 2가지에는 특수한 역할이 존재하기 때문에 사용하지 않는것이다.
0.0.0.0 주소는 현재 네트워크 또는 이 장비를 나타내며 boot시에 사용한다.
255.255.255.255(모두1인경우) 주소는 현재 네트워크에 접속된 모든 장비를 나타낸다. LAN의 경우 방송을 할 때 사용된다.
127.....로 시작하는 주소는 loopback 테스트 즉, 자체 컴퓨터에게 IP 패킷을 전송할 때 사용한다. 이 주소를 가진 패킷은 외부로 나가지 않고 자신의 상위 계층으로 전달된다.

메시지 분할 전송

인터넷이 여러 네트워크들로 구성되어 있을 때 각 네트워크마다 처리할 수 있는 최대 패캣의 크기가 다를 수 있으므로 인터넷을 통해 IP 패킷을 전송하기 위해서 다음과 같은 IP 패킷의 분할/재조립 기능이 필요하다.
어떤 네트워크에서 한 번에 전달할 수 있는 패킷의 최대 크기를 MTU(Maximum Transmission Unit)라고 한다.
예를 들어 1200 바이트 크기의 메시지를 MTU가 500 바이트인 하위 네트워크로 전송하면 다음과 같이 세 개의 패킷으로 세분화되어 전송된다.

ID = x, M = 1, offset = 0 (데이터 크기 = 480 바이트)

ID = x, M = 1, offset = 480(데이터 크기 = 480 바이트)

ID = x, M = 0, offset = 960(데이터 크기 = 240 바이트)

위에 식을 보면 패킷의 데이터가 480 바이트인 이유는 IP 헤더 20 바이트를 포함하여 총 패킷의 크기가 500 바이트로 되어야 하기 때문이다.
offset = 0의 의미는 이 패킷이 전체 메시지의 첫 메시지 부분인것을 의미한다. 두 번째 패킷에서 offset = 480의 의미는 이패킷이 전체 메시지의 481번째 바이트 이후의 데이터를 포함하고 있는 것을 의미한다.
offset은 실제로는 바이트 단위가 아니라 8바이트 단위의 크기로 표시된다. 즉, 위의 예에서 offset에는 480대신 60의 값이 들어간다.
위에서 More 비트 M은 마지막 패킷만 0으로 설정한다.
세분화를 한 후에는 이 세분화된 다수의 패킷들로부터 원래의 메시지를 재구성할 수 있도록 하기 위해서 각 패킷의 identification 필드에 동일한 값을 지정해 주어야 한다.(위에서 ID = x라고 적어놈)
즉, 이들 세분화된 다수의 패킷들이 하나의 그룹에 속한다는 것을 알려주어 수신측에서 다시 원래의 메시지를 재조립할 수 있다.
만일 전체 메시지를 구성하는 패킷중 하나라도 분실되면 일반적으로 수신측에서는 전체 메시지를 버린다.
메시지의 재조립은 중간의 라우터에는 실행되지 않고 최종 수신측에서만 이루어진다.
Flag의 세 번째 비트가 More 비트인데 More = 1이면 이 IP 패킷과 다음에 전송되는 패킷이 트랜스포트 계층에서는 본래 하나의 메시지였으나 세분화 되어 전송된다는 것을 나타낸다.
따라서 한 메시지의 마지막 부분을 구성하는 패킷, 또는 메시지가 단 한 개의 패킷으로 구성된 경우의 More 비트는 0이 된다.
세분화는 송신장비뿐 아니라 라우터에서도 이루어질 수 있는데 패킷을 수신한 쪽의 MTU보다 전달할 네트워크의 MTU가 작으면 라우터에서 필요한 크기로 세분화를 한다.
그런데 라우터에서 추가로 패킷 세분화를 하면 수신측에서의 재조립 과정(패킷 분실을 할 경우의 처리 방법등)이 복잡해지므로 가능한 라우터에서의 분할을 피하는것이 좋다.
그래서 현재 송신 호스트에서 최초로 패킷을 전송할 때 중간의 라우터가 세분화를 하는 일이 없도록 충분히 작은 크기로 만들어 보내는 것이 필요하다. 누가? 호스트가

Path MTU

송신지와 수신지 사이에 여러 개의 서브네트워크를 경유할 때 이네트워크들의 MTU들 중 최소의 크기의 MTU를 두 호스트 사이의 Path MTU라고 한다.
송신측이 이 path MTU 크기를 알아내어 전송할 메시지의 크기를 path MTU 크기로 세분화를 한다면 중간 라우터에서는 세분화는 일어나지 않게 된다.
path MTU를 찾아내기 위해서 Flag의 두 번째 비트 DF를 사용한다. DF = 0이면 이 패킷의 세분화를 허용하는 것이며 중간의 라우터가 필요에 따라 이 IP 패킷을 작은 크기로 나누는 것을 허용한다는 뜻이다.
그러나 DF =1이면 세분화 금지를 나타내는데 중간의 라우터가 이 패킷을 세분화 하지 못하도록 한다. 즉 DF =1이면서 IP패킷의 크기가 path MTU보다 큰 경우에는 중간의 라우터에서 오류가 발생하여 송신측에게 이를 알려주게 된다. 이러한 특성을 이용하여 path MTU의 크기를 알아낼 수 있다.
예를 들어 TCP 계층에서 일정 크기의 패킷을 DF = 1로 하여 전송했을때, 이것이 목적지에 전달되지 못하고 오류가 발생하면 패킷의 길이를 조금 줄여서 다시 전송하는 과정을 전송이 성공할 때까지 반복하여 path MTU discovery 프로토콜이라고 한다.

DHCP

원래 IP 주소는 호스트마다 하나씩 고유 주소를 배정해주어야 한다.
그러나 이렇게 모든 컴퓨터가 각각 고유의 IP 주소를 배정받기에는 현재 4바이트 길이의 IP 주소로는 주소의 수가 부족하다.(디바이스들이 너무 많음)
이를 해결하기 위해서 컴퓨터마다 IP 주소를 미리 지정하지 않고, 즉 고정 IP 주소를 배정해주지 않고, 컴퓨터가 인터넷을 사용할 때마다 IP 주소를 임의로 배정해주는 DHCP(Dynamic Host Configuration Protocol)를 사용한다.
DHCP에 따라 IP 주소를 배정해 주는 서버를 DHCP 서버라고 한다.
DHCP는 초고속망을 접속된 각 가정에 IP 주소를 배정하는 데에 널리 사용되는데, 초고속망 가입 통신회사에서 DHCP 서버를 운영한다.
즉, 초고속망에 가입된 가정이나 사무실에서는 고정 IP 주소를 사용하는 것이 아니라, 인터넷 서비스 사업자(ISP: Internet Service provider)가 배정해주는 동적 IP 주소를 사용한다.
DHCP 서버가 일정한 수의 IP 주소 풀(운영체제의 메모리 풀과 같은 용어를 의미)을 운영하면서 이 서버로 연결되는 가입자에게 여분의 IP 주소를 배정함으로써 소수의 IP 주소를 가지고 여러 가입자에게 인터넷 서비스를 제공할 수 있다.
DHCP는 대형 회사나 대학 등에서도 사용한다.
회사에서 배정받은 또는 대학에서 배정받은 IP 주소를 가지고 사무실에 있는 모든 PC 마다 또는 캠퍼스에 있는 모든 PC마다 고유 IP 주소를 배정하기에는 IP 주소가 부족하므로 DHCP를 사용하여 현재 사용하지 않는 IP 주소를 돌아가면서 공유하는 것이다.
오DHCP를 사용하면 편리한 점은 사용자가 일일이 주소를 직접 입력하지 않아도 된다는 것이다. 특히 노트북 사용자가 고정 IP를 사용한다면 장소를 옮길 때마다 자신의 인터넷 환경, DNS 서버 주소, 현재의 네트워크에서 사용할 자신의 새로운 IP 주소등을 매번 다시 설정해 주어야 한다.
따라서 사용자가 굳이 고정 IP를 사용하지 않아도 된다면 임의의 IP 주소를 배정받는 것이 편리하다.

고정 IP

그러나 어떤 컴퓨터는 이렇게 DHCP를 이용할 수 없고 반드시 고정 IP를 사용해야만 하는 경우가 있다. 웹서버나 어떤 네트워크 응용 서비스 프로그램을 실행하는 서버는 고정 IP를 반드시 사용해야 한다.
왜냐하면 인터넷 상의 임의의 다른 호스트가 이 서버를 찾아오려면 미리 정해진 IP 주소를 외부에 알려줘야 외부에서 이 서버를 찾아올 수 있기 때문이다.
즉, 서버로 운영할 호스트는 DHCP를 사용하면 안 되고 고정 IP를 ISP로부터 배정받아서 사용해야 한다.

NAT(Natwork Adrress transfer)

DHCP가 주소가 부족한 걸 전부 해결해주지 않는다.
남이 안쓰는걸 빌려와서 사용하는것일 뿐 주소는 부족하다.
인터넷을 처음 설계할 때는 4바이트(32비트) 길이의 IP 주소이면 전세계 컴퓨터들을 충분히 구분할 수 있을 것으로 생각했다.
그러나 현재 인터넷에 연결되는 장비 수는 그 수를 세기도 어려울 정도이며 수억대 이상일 것으로 예측된다. 모든 장비에 고정 IP를 배정하는 것은 불가능하다. 한편 누구나 임의로 라우터를 추가로 설치하고 장비들을 인터넷에 연결하고 있는데, 이 장비들이 고정 IP 주소를 배정받는 것은 주소의 수도 부족하지만 IP 주소를 배정하는 것 자체도 매우 번거롭다.
현실적으로 대부분의 가정에서는 DSL(디지털 가입자선로, Digitial Subscriber Loop)을 통해 인터넷에 접속되어 있고, 각 가정마다 수~수십 대의 노트북 등의 컴퓨터가 인터넷에 접속되어 있따.
그러면 이 장비들에게 IP 주소를 어떻게 배정할 지가 큰 문제가 되는데, 이를 해결하기 위해서 NAT 프로토콜이 사용된다.

NAT의 동작 원리

가족의 우편물을 받을때 집의 우편물 주소를 다르게 적지 않듯이 IP주소도 마찬가지이다.
NAT의 동작 원리를 간단히 정의하면, 가정이나 사무실 내의 컴퓨터들에게는 고정 IP를 배정하기 어려우므로 그 가정에서는 다른 곳과 중복될 수 있는 임의의 IP 주소를 사용하되 외부로 나갈 때에는 그 집에 배정된 대표 IP 주소로 변환하겠다는 것이다.

이 그림은 NAT의 동작 과정들을 보여준다. 패킷을 수신 받을 때에는 그럼 어떤 호스트에게 전달하냐라는 의문이 나올 수 있는데 NAT box로 들어온 정보는 10.0.0.1로 변환 된 뒤에 각 호스트에 맞는 포트번호에 맞게 전달이 된다. 포트번호는 16비트를 사용하므로 약 64000개의 장치를 구분할 수 있다.
반대로 패킷이 나갈 때에는 하나의 IP주소인 198.60.42.12 하나로 돌아다니게 된다.
NAT 프로토콜에서 내부 장치를 구분하기 위해서는 TCP나 UDP 계층에 정의된 포트번호를 사용한다.

포트번호

포트번호는 IP 패킷구조 안에 있는게 아니고 TCP나 UDP안에 있다.(기억이 안나면 그 전에 있는 IP 패킷구조 그림을 참조하자) 포트번호는 TCP나 UDP를 이용하는 응용 프로세스를 구분하는 번호이다. 이 포트번호를 활용하여 통신 장치를 구분하는 두 가지 목적으로 사용된다.
예를 들어 어느 집에 3대의 컴퓨가 있고 그 집의 라우터가 배정한 내부 IP 주소가 각각 아래와 같이 배정되었다고 하자.

컴퓨터1 : 192.168.0.5

컴퓨터2 : 192.168.0.6

컴퓨터3 : 192.168.0.7

컴퓨터2에서 어떤 응용 프로그램이 실행되고 있으며 포트번호로 6000번을 사용하고 있고, 컴퓨터3에서 어떤 응용 프로그램이 포트번호를 4000번을 사용하고 있다고 하자.
이 두 프로그램이 외부로 접속하기 위해서 NAT 테이블에 등록된 번호는 아래와 같다.

192.168.0.6:6000 -> 203.25.66.36:7001

192.168.0.7:4000 -> 203.25.66.36:7002

위 첫줄의 의미는 컴퓨터2에서 6000번 포트번호를 사용하는 프로세스는. 외부로 나가고 들어올 때는 이 집의 대표 IP주소인 203.25.66.36와 포트번호 7001을 배정받았고, 둘째 줄의 의미는 컴퓨터3에서 4000번 포트번호를 사용하는 프로세는, 외부로 나가고 들어올 때는 IP주소가 203.25.66.36이며 포트번호로 7001을 새로 배정받았다는 것을 나타낸다.
이러한 번호의 매핑 정보를 NAT 변환 테이블(NAT translation table)에 기록해둔다.
외부에서 이 집으로 들어오는 패킷은 모두 목적이 IP 주소로서 203.25.66.36 하나만 사용하고 이 집에서 외부로 나가는 패킷의 발신지 주소도 모두 203.25.66.36 하나만 사용된다.
어떤 집에 배정된 대표 고정 IP 주소가 하나 뿐이라도 NAT를 사용하면 이 집 내부에서는 여러 개의 임시 IP 주소를 사용할 수 있다.
NAT를 사용함으로써 주소 부족 문제를 완벽히 해결했고 IPv6넘어가지 않아도 되게 되었다.
핵심은 외부적으로 보았을때 IP 주소가 하나라 보이게끔 설정되어있고 포트번호를 통해 그 내부를 구분한다는 것이다.
집안 배부에 있는 여러 장치들은 임의의 IP 주소를 사용할 수 있는데 보통 192.168.0.0 부터 192.168.255.155 범위의 IP 주소를 사용할 수 있다.
이렇게 임의로 배정되는 IP주소는 이 집 내부에서만 유일하게 구분되면되는 것이며 옆집이나 임의의 다른 집에서도 똑같은 IP 주소를 사용할 수 있따.
마치 한 회사의 내선 번호가 102번이고 다른 회사의 내선번호가 똑같이 102번이 있을 수 있는 것과 같다.
NAT를 처리하는 라우터는 외부로 나가는 패킷의 IP주소와 포트번호를 새로 배정하여 내보내고 외부에서 이 IP 주소와 포트번호를 가지고 들어오는 패킷은 다시 역순으로 내부 IP 주소와 원래 포트번호로 매핑한다.
NAT에서 사용하수 있도록 배정되는 주소 범위는 IP 주소 A, B, C 클래스 타입에 따라 다음과 같이 세 가지가 사용된다.

A타입 10.0.0.0 ~ 10.255.255.255/8

B타입 172.15.0.0 ~ 172.31.255.255/16

C타입 192.168.0.0 ~ 192.168.255.155/24

NAT의 문제점

NAT 프로토콜은 부족한 IP 주소를 각 가정이나 개인, 소규모 회사에게 모두 배정해줄 수 없기 때문에 채택된 임시방편이다.
NAT의 문제점은 외부로 먼저 패킷이 나가야만 비로소 그 장치가 외부로부터 오는 패킷을 먼저 받을 수 있다는 것이다. 즉 외부 인터넷에서 집안 내부의 장치로 먼저 패킷을 보내는 것이 불가능하다.
왜냐하면 아직 NAT 테이블이 만들어지지 않았기 때문이다. 따라서 NAT를 사용하는 라우터 내부에서, 예를 드면 대부부의 가정에서 웹서버와 같은 서버 프로그램을 운영하는 것이 어렵다.
왜냐하면 서버가 먼저 외부의 클라이언트로 패킷을 보낼 수는 없으므로, 외부의 임의의 장치(클라이언트)가 이 NAT 라우터 내부의 서버를 먼저 찾아낼 수가 없기 때문이다

ARP/RARP

MAC주소: 물리적인 주소를 나타내며 기기의 고유번호를 의미.

IP 주소를 가지고 LAN에 도착해서 정보를 넘겨야하는데 이때 MAC주소가 필요하다.

ARP(Address Resolution Protocol)은 LAN 내에서 특정 IP 주소를 가지고 있는 노드(호스트 또는 라우터)의 MAC 주소를 알아내는 절차를 말한다.
ARP 프로토콜이 필요한 이유는 LAN에서 모든 데이터는 이더넷 프레임등 MAC 프레임에 실려서 전달되며 이 때 "IP 주소가 아니라" 48비트의 MAC 주소가 사용되기 때문이다.
따라서 LAN에 접속된 호스트에게 IP 패킷을 전달하려면 먼저 그 장비의 MAC 주소를 알아야 하는데, 이와 같이 IP 주소를 가지고 그 호스트의 MAC 주소를 알아내는 절차를 ARP라고 한다.

위 그림은 Telnet으로 현재 원격접속을 한 뒤 1단계에서 도메인을 32비트 주소로 바꿔준뒤 4단계에서 ARP 요구 방송을 한다. 예를 들면 192.0.0.0주소인 사람? 그러면 그와 관련된 물리적 MAC주소를 호스트가 응답한다. 이와 같이 축적되는 정보를 ARP 테이블을 구성해서 정보를 축적하여 물어보면 빠르게 답변할 수 있는 환경을 구축한다.

MAC 주소는 무리주소(physical address)라고도 부르는데 각 노드에 있는 어댑터(LAN 카드)가 가지고 있는 고유번호이다.
ARP를 설명하기 위해서 telnet의 동작 절차를 설명하겠다.
예를 들어 telnet cc.kangwon.ac.kr라는 명령을 내리면 응용 프로그램 telnet은 먼저 cc.kangwon.ac.kr 호스트의 IP 주소가 192.203.144.11인 것을 찾는다.
telnet은 위에서 알아낸 IP 주소를 TCP에게 알려주고 이곳으로 접속을 하도록 요구한다.
TCP는 목적지 호스트의 주소를 가지고 "종점간 연결 설정"을 시도하며 이 연결 설정 요구가 들어있는 패킷을 IP 계층을 통해 전송한다.
이 때 IP 계층은 목적지 호스트의 netid가 자신의 netid와 같은지(위 예에서 방송을해서 주소를 물어보았던 호스트가 도착지 호스트인지 확인하는 경우) 비교하여 목적지가 같은 LAN 내에 있으면 LAN을 통하여 바로 패킷을 전송하며 만일 목적지가 같은 LAN 내에 있지 않은 경우에는 패킷을 디폴트 게이트웨이(출입구)로 전송하여 외부로 나가도록 한다.
또한 목적지 호스트 또는 디폴트 게이트웨이로 패킷을 보내기 위해서 ARP의 도움을 받아야한다.

ARP

ARP의 동작은 다음과 같이 이루어진다. 먼저 목적지 호스트의 MAC 주소를 찾기 위하여 ARP request 패킷을 LAN 내의 모든 장비에게 방송한다.
이 ARP request 패킷에는 목적지의 IP 주소가 실려 있고 이 IP 주소에 해당하는 장비는 응답을 해달라는 의미가 들어있다.
만일 이에 해당하는 목적지 호스트(즉, cc.kangwon.ac.kr)가 같은 네트워크에 있었다면 ARP request에 응답을 하며 이 때 자신의 MAC 주소를 알려주는것이다.(이 때 테이블이 형성된다.)
그런데 동일한 목적지 호스트에 IP 패킷을 연속하여 보낼 때 매번 ARP를 사용하면 ARP를 처리하기 위한 패킷들을 자주 전송하게 되어 트래픽이 증가하게 된다.
이러한 오버헤드를 피하기 위해서 ARP로 얻은 최근의 정보는 캐시에 기록해 두고 ARP를 구동하지 않는 방법이 있다.
그러나 MAC 주소와 IP 주소의 관계는 수시로 바뀔 수 있으므로 캐시에 있는 정보는 일정시간(보통 15분)만 유효하게 하며 이 시간이 지나면 ARP의 캐시 정보가 리셋된다.
한편 ARP request는 ARP의 대상이 되는 목적지 노드에게 자신의 IP 주소와 MAC 주소의 관계를 알려주는 기능도 수행한다.
다시 말하면 ARP request에는 ARP를 요구하는 송신지 노드의 IP 주소와 MAC 주소가 들어 있으므로 상대방(목적지)의 ARP 테이블 (즉, ARP 캐시 정보)에 이를 등록해 두었다가 이 ARP request를 보낸 노드로 패킷을 보낼 때 사용하게 된다.
상대방과 양방향 통신을 할 가능성이 높으므로 이렇게 해두는 것이 상대방이 ARP를 다시 요구할 필요가 없게 되어 효율적이다.(위에서 말한 방송후 테이블을 만들어 나중에 찾기 쉽게 만드는 작업)
위에 설명한 "ARP request에 의한 캐시 업데이트"는 ARP를 요구한 목적지 노드 뿐 아니라, 이미 이 송신자에 해당하는 ARP 캐시를 가지고 있던 다른 노드들에서도 이루어진다.(즉, 정보의 업데이트).
이 때는 ARP 캐시의 내용이 없어지는 타이머 값을 새로 리셋하면 된다.
ARP의 역 과정, 즉 48비트 MAC 주소를 알고 있을때 그 장비의 IP 주소를 알아내는 과정을 RARP(reverse ARP)라고 한다.

ICMP

도로의 교통통제를 하는 역할을 하는 사람들과 비슷하다.
인터넷에서 IP 패킷의 전달을 직접 다루는 프로토콜은 앞에서 설명한 IP 프로토콜이다.
IP프로토콜이 정상적으로 잘 동작하도록 돕는 기능이 필요한데 예를 들어 라우터에서 오류가 발생하여 패킷이 목적지로 패킷이 전달되지 않으면 이 사실을 송신 장치로 알려줘야한다.
이 때 송신지로 이러한 사실을 알려주기 위해서 ICMP가 이용된다. 오류 발생 원인의 예로 목적지 호스트를 찾지 못하거나 (host is unreachable), 패킷을 재조립하는 과정에서 오류가 발생하거나, TTL 값이 종료되어 더 이상 패킷을 전달하는 것이 멈추거나, IP 헤더에서 checksum 오류가 발생하는 등이 있을 수 있다.
ICMP는 라우팅 오류 발생시 외에도, 제어 정보를 전달하는 데에도 사용되는데 예를 들어 ICMP-Redirect는 라우터가 더 나은 다른 라우팅 정보를 알게 되었을 때(예를 들면 더 좋은 길을 발견했을때) 이를 송신지에게 알려줄 때 사용된다.
ICMP는 이외에도 ping이나 traceroute 같이 인터넷의 동작을 확인하는 명령문을 처리하는데도 사용된다.
ping은 이 명령을 내리는 컴퓨터와 인터넷 상의 임의의 어떤 컴퓨터가 잘 연결되어 있는지를 확인하는 명령문이다.
traceroute는 어떤 목적지 컴퓨터까지 연결된 중간 경로를 알아내는 명령문이다.
ICMP 메시지는 IP 패킷에 실려서 전달되며 타입(type) 값을 보고 어떤 메시지인지 구분할 수 있다. ICMP 메시지 타입의 예와 각각의 이유는 아래와 같다.

Echo Request : 이 메시지를 받은 목적지는 ICMPEcho Reply를 보낸다

Echo Reply : Echo Request 메시지를 수신한 컴퓨터에서 응답하는 메시지

Destination Unreachable : 라우터가 목적지 컴퓨터를 찾을 수 없음

Time Exceeded : TTL 값이 0이 되어 더 이상 패킷을 전달할 수 없음

Redirect : 패킷이 잘못 라우팅되고 있음(라우팅 테이블을 업데이트 하도록 요구함)

Timestamp Request, ICMP Timestamp Reply : 현재 시각을 기록해서 보낸다.

Ping 명령을 처리하기 위해서 Echo Request와 Echo Reply를 사용하는데, Ping 명령을 내린 컴퓨터에서 Echo Request를 보내면 목적지에 Echo Reply를 응답하며 이를 보고 목적지가 제대로 동작하고 있는지를 확인할 수 있다.
Traceroute 명령을 내린 송신측에서는 TTL 값을 처음에는 1, 다음에는 2, 다음에는 3, 이런 방식으로 1씩 증가시키면서 목적지를 향해 패킷을 보낸다.
그러면 각각 목적지까지 경로상에 있는 첫 번째 라우터에서, 두 번째 라우터에서, 세 번째 라우터가 각각 차례로 Time Exceeded 메시지를 보내올것이며 이 메시지에 라우터의 IP 주소가 실려 있으므로 송신자로부터 최종 목적지 사이에 있는 모든 라우터의 주소를 알아낼 수 있다.
Timestamp Request, ICMP Timestamp Reply는 네트워크의 지연시간을 측정하는데 사용된다.

IGMP

IGMP는 멀티캐스팅을 처리하는 프로토콜인데 실제로는 사용을 안한다. 생각해보자 지구상의 모든 사람들이 카카오 단톡방을 만든다고 생각해보자 매우 복잡할 것이다. 그래서 사용 안한다.

서브네팅(subnetting)

인터넷 주소는 총 4바이트 길이이나 기능적으로 두 부분으로 나누어져있어, 네트워크를 구분하기 위해서 netid를, 네트워크 내의 호스트를 구분하기 위해서 hostid를 사용하고 있다.
라우팅에서는 기본적으로 netid 부분을 처리한다. 즉 라우팅이란 netid보고 해당 장비가 속한 네트워크(라우터)까지 전달하는 것이 일 차 목표이고 그 네트워크 내에서(보통 LAN을 의미) hostid를 보고 최종 장치로 패킷이 전달된다.
그런데 현재 netid의 수는 한정되어 있어 netid 자원이 부족하다. 그리고 각 네트워크 주소(netid) 내에 항상 최대 hostid 수만큼의 호스트가 연결되어 있는 것이 아니므로 주소의 낭비가 있게 된다.
예를 들어 약 250 여개의 장비를 구분할 수 있는, 클래스 C 주소를 사용하는 네트워크에서 50개의 hostid만 사용한다면 나머지 200 여개의 hostid는 낭비가 된다.
이러한 비효율성은 클래스 B의 경우가 더 심각하여 하나의 netid 내에 64000개의 호스트를 구분할 수 있는 hostid가 있어 주소가 낭비된다.
이러한 주소의 낭비를 줄이고 주소 체계를 효율적으로 사용하기 위해서 하나의 netid에 속하는 네트워크를 다시 여러 개의 작은 네트워크로 나누어 사용하는 것을 서브네팅이라고 한다.
4바이트의 IP 주소 중에 netid 부분을 구분하기 위한 mask를 subnet mask라고 하는데, 클래스 A주소의 디폴트 subnet mask는 255.0.0.0이고 클래스 B는 255.255.0.0, 클래스 C는 255.255.255.0이다.
서브네팅을 구현하려며 이 subnet mask를 원하는 길이로 바꾸어서 어디까지가 새로 정의하는 netid 부분인지 경계를 나타내주면 된다.
아래의 그림은 클래스 C의 경우 예를 보였다.

이 그림은 hostid 부분을 사용해서 nestid 부분을 확장한것을 확인할 수 있는 그림이다. 그리고 밑에 192는 2^7+2^6승은 더한 192값을 의미한다.

클래스 B 주소를 서브네팅하는 경우의 예를 보겠다.(위 그림 아님)
예를 들어 클래스 B의 주소로 배정된 네트워크에서 subnet mask로 255.255.192.0를 사용한다면 이것의 의미는 원래의 netid의 크기는 16비트 이고(상위 16비트), 서브넷을 구분하기 위해서 세 번째 주소 바이트중 상위 2비트를 subnetid로 사용하고 hostid로는 하위 14비트를 사용한다는것을 의미한다.
즉, 하나의 클래스 B주소를 4개의 서브넷으로 나눈다.
서브네팅은 netid로 구분된 네트워크를 다시 작은 네트워크들로 나눈 것이라고 볼 수 있으며 따라서 라우팅에서도 netid 부분만 사용하면 안되고 netid + subnetid를 묶어 새로운 네트워크 주소처럼 처리해 주어야 한다.
라우터에서는 목적지 IP 주소를 자신의 subnet mask로 AND하여 이 부분을 새로운 netid 처럼 취급하면 된다.
즉, 네트워크 주소 길이가 subnetid 만큼 길어졌다고 볼 수 있다.

'컴퓨터네트워크' 카테고리의 다른 글

4.트랜스포트 프로토콜(세그먼트, 포트번호, well-known port, TCP 연결 설정, TCP 데이터 송수신, TCP 흐름제어, 윈도우 흐름제어, 재전송, Jacobson/Karels 알고리즘, 데이터 경계 표시, TCP 옵션, UDP, UDP헤.. (0)	2021.09.05
3.라우팅(포워딩, 링크상태 라우팅, Autonomous System, OSPF, 도메인간 라우팅, 도메인내 라우팅, BGP, CIDR, 방송형라우팅, 멀티캐스트 , MBONE, Mobile 네트워크의 라우팅, AD HOC 네트워크의 라우팅, 혼잡제.. (0)	2021.09.05
1.인터넷(TCP/IP, UDP, 프로토콜 모음집) (0)	2021.09.05