IP Datagram format

• ver

• version을 의미한다. 프로토콜의 버전이 IPv4인지 IPv6인지를 나타낸다.

• head.len

• header의 길이를 의미한다. option 필드 때문에 header의 길이가 가변적인데 헤더의 길이를 명시함으로써 어디까지가 헤더인지 알 수 있다.

• type of service

• 해당 datagram의 혼잡 여부, 우선 순위, 신뢰성, 처리량 등의 정보를 담고 있는 필드이다. 8비트로 이루어져 있다.

• length

• 패킷의 길이를 나타낸다. 16비트로 이루어져 있으며 따라서 패킷 사이즈는 최대 2^16 바이트이다. 이보다 큰 datagram은 쪼개야 한다.

• 16-bit identifier, flags, fragment offset

• 데이터의 길이가 전체 패킷 길이보다 길어 쪼개야 할 필요가 있을 때 각 패킷들 간의 순서 보장을 위한 부분이다. 이 때 쪼개는 작업을 fragmentation 이라고 한다.

frarmentation이 일어나면 바로 다음 라우터에서 재조합 하는 것이 아니라 목적지에서 마지막에 재조합한다는 것이다.

• time to live
  앞글자만 따서 보통 TTL 이라고도 한다.
  이는 패킷의 수명을 의미한다.
  만약 주소 부분에 오류가 생겨서 목적지를 찾지 못하고 라우터들 사이를 이리저리 돌아다니는 패킷이 생길 수가 있는데, 이러한 패킷들이 영영 네트워크 상에 조재해선 안되므로 패킷의 수명을 지정해준다.

수명의 단위는 홉(hop)이다. 라우터를 하나 이동할 때마다 TTL 필드가 1씩 감소한다. 이 필드가 0이 되면 해당 패킷이 삭제된다. 이는 ICMP 프로토콜을 통해 삭제되었다는 사실을 송신자에게 알려 준다.

• upper layer
  upper layer, 상위 계층 필드이다. 말 그래도 IP Datagram의 상위 계층, 즉 전송 계층에서 TCP인지 UDP인지 어떤 프로토콜을 사용하고 있는지를 나타낸다.

• header checksum
  header checkusm은 TCP/UDP 헤더의 checksum 필드와 동일하게 오류를 검증하는 작업에서 비교하는 용도로 사용한다.

헤더의 필드들을 비트 연산, 보수 연산을 수행하여 checksum 작업을 수행하기 때문에, 헤더의 내용이 바뀌면 checksum 값도 바뀌어야 한다. 그런데 라우터 사이를 이동할 때마다 TTL 홉이 줄어든다. 따라서 헤더의 내용이 바뀌므로, 라우터 사이를 이동할 때마다 checksum 필드도 매번 변한다.

그리고 이러한 checksum 오류 검증은 헤더의 내용에 대해서만 이루어지며 payload data의 변조 여부는 신경쓰지 않는다.

• source IP address, destination IP address

출발지와 목적지의 IP 주소를 나타낸다. 라우터는 이 부분을 routing table과 대조하여 forwarding 작업을 수행한다. 32비트로 이루어져 있다.

• options
  timestamp, record route token 등 기타 정보를 담고 있으며 선택사항이다. 길이 또한 가변적이어서 headlen 필드에서 options 필드를 포함한 전체 헤더의 길이를 명시해 주어야 한다.

IP addressing

IP 주소(IP address)란 각각의 라우터 또는 호스트의 interface를 식별하기 위한 32비트의 식별자이다.
(interface는 호스트 및 라우터와 물리적 링크 간의 연결을 의미한다.)

흔히들 IP 주소라고 하면 컴퓨터 등 디바이스를 식별할 수 있다고 생각하는데, 제대로 말하면 인터페이스의 주소이다. 만약에 한 컴퓨터에 랜카드를 여러 개를 꽂으면 IP 주소를 여러 개 가질 수 있다.

Subnets

서브넷은 중간 라우터를 통과하지 않고 물리적으로 서로 도달할 수 있는 장치 인터페이스를 의미한다.

Subnet mask

서브넷의 구현은 서브넷 마스크를 통해 가능하다.
서브넷 마스크는 IP 주소를 네트워크 및 호스트 주소와 분리한다. 이를 통해 어디까지가 네트워크 주소인지 명시적으로 나타내 줄 수 있다.

예를 들어 /24라고 하면 이 주소의 상위 24비트가 네트워크 주소이다.
C 클래스는 기본적으로 /24 서브넷 마스크를 지닌다. (C 클래스는 8비트가 호스트 영역이기 때문에)
2^8개의 호스트를 가질 수 있는 이 네트워크를 128, 128개의 호스트를 가지는 네트워크 두 개로 나누고 싶다면 한 비트만큼을 네트워크 부분으로 옮기면 된다. 그러면 서브넷 마스크는 /25가 된다.

분할을 많이 하면 그만큼 하나의 서브넷에서 수용할 수 있는 호스트의 수가 줄어들게 되므로, 네트워크의 규모에 따라 서브넷 마스크를 적절히 설정하는 것이 필요하다.

클래스의 개념만 사용한다면 호스트의 낭비가 발생할 수 있다. 큰 네트워크를 작게 분할하여 필요한 규모에 맞게 사용하면 낭비되는 IP 주소를 줄일 수 있다. 더 세세하게 네트워크를 나누면 네트워크 라우터의 수는 많아지지만 관리되는 호스트의 수는 줄어들어 관리하기에 용이해진다.

이와 비슷한 맥락으로, 네트워크에 속하는 모든 호스트에게 메시지를 보내는 브로드캐스팅 시에도 메시지를 보내는 호스트의 개수를 적절하게 줄임으로써 성능의 저하를 막을 수 있다.

DHCP(Dynamic Host Configuration Protocol)

서브넷 마스크가 네트워크를 분할하여 호스트의 관리를 용이하게 하는 것이라고 하면, 이제는 그러면 어떻게 IP 주소가 실질적으로 할당되는지 확인해야한다.

DHCP는 IP 네트워크에 사용되는 네트워크 프로토콜이다. DHCP는 IP 주소 및 기타 통신 매개변수를 네트워크에 연결된 장치에 자동으로 할당한다.

동적으로 IP 주소를 할당하기에 사용하지 않는 동안 낭비되는 IP 주소는 사라진다.

각 네트워크에는 DHCP 서버가 있다. 호스트가 네트워크에 접속하면, IP 주소를 할당받기 위해 DHCP 서버와 통신한다.

DHCP client-server 시나리오

• DHCP discover

클라이언트가 먼저 서버를 찾기 위해서 메시지를 보낸다. DHCP 서버의 주소를 모르게 때문에 브로드 캐스팅 해야 한다. 브로드 캐스트 메시지이므로 DHCP 서버를 포함해 서브넷 안의 모든 호스트가 이 메시지를 들을 수 있다.

• DCHP offer

서버는 이에 응답한다. 아직 클라이언트는 IP 주소가 없기 때문에 서버 역시 브로드캐스트 메시지를 보낸다. 다만 자신의 IP 주소 (source IP address)는 알려준다.

• DHCP request

DHCP 서버의 존재 및 자기가 사용할 수 있는 IP 주소를 알아낸 클라이언트는 그 주소의 할당 요청을 서버에게 보낸다. 이 때도 브로드캐스트 메시지로 보낸다.
(여러 개의 DHCP 서버가 존재할 수 있고, 그 서버들에게 모두 클라이언트가 이 주소를 사용한다는 사실을 알려야 하기 때문에 브로드캐스트 메시지로 보낸다.)

• DHCP ack

서버는 알겠다는 메세지와 함께 다양한 네트워크 정보들을 전달한다. 다음과 같은 정보들이 포함된다.

• first-hop router (다음 향할 라우터)의 주소
• DNS 서버의 이름과 IP 주소
• 네트워크 마스크 (어디까지가 네트워크 주소인지를 나타냄)

IP address: How to get one?

네트워크는 어떻게 서브넷 부분을 얻을까?

ISP가 가지고 있는 IP address 중 일부분을 취하게 된다.

어떤 ISP의 네트워크인지를 나타내는 ISP block 부분(... ... 0001 까지) 뒤에 각 organization마다 다른 subnet 네트워크 주소를 추가로 할당받고 있음을 확인하고 (000 부터 111 까지), 서브넷 마스크 부분이 /20에서 /23으로 바뀐 것을 확인할 수 있다.

Hierarchical addressing

위와 같이 Fly-By-Night-ISP 가 있고 ISPs-R-Us 가 있다고 한다.
두 네트워크는 서로 네트워크 주소가 다르다. 그리고 각각의 네트워크의 특정 요청을 자신한테로 보내면 된다는 것을 인터넷에 알려준다.

예를 들어서 Fly-By-Night-ISP 는 200.23.16.0/23 으로 시작하는 IP를 보내라고 한다.

이 때 organization 1이 ISPs-R-Us 밑으로 이동한다고 가정한다.

그러면 다른 자식들과 다른 것들이 ISPs-R-Us 밑으로 들어오게 된다. 그러면 이동한 organization 1은 주소를 변경해야 하는가?

변경하지 않아도 된다.
그 이유는 routing algorithm은 longest prefix matching 원칙을 따르기 때문에 200.23.18.0/23 과 200.23.16.0/20 중에서 전자가 다 long한 prefix 이므로, organization 1로 향하는 패킷을 정상적으로 ISPs-R-Us 쪽으로 보낼 수 있다.

ISP는 ICANN(Internet Corporation for Assigned Names and Nubmers, 국제인터넷주소관리기구)을 통해 ISP block을 할당받는다.