[컴퓨터망] 4. Network Layer(Internet Protocol)

Network Layer : Internet

지금까지 네트워크 계층의 Data plane과 Control Plane에 대해 학습했다.

IP Datagram Format

IPv4 패킷의 내부 구조를 알아보자.

Ver

IP 프로토콜의 버전이 저장된 필드이다. IPv4이기 때문에 4가 들어가 있다.

 

Head Len

헤더 길이를 byte단위로 저장한 필드다. 옵션 길이에 따라 헤더 길이가 달라지기 때문에 가변 길이다. 대부분의 IPv4 데이터그램의 헤더는 20byte이다.

 

Type of Service

각 패킷마다 제공하는 서비스를 저장한 필드다. 예를 들어서 실시간 데이터 그램과 비실시간 트래픽 등을 저장한다. 0~5까지는 diffserv, 6~7은 ECN을 나타낸다.

 

Length

헤더와 payload를 총 합친 길이를 저장한 필드이다.

 

16bit identifier, flags, fragment offset

이 세 가지 필드는 fragmentation과 reassembly를 위한 필드이다. 각 링크 계층은 패킷을 보낼 수 있는 크기가 저장되어 있다. 이를 MTU라고 정의하는데, 링크로 들어온 패킷이 MTU보다 큰 경우에, 이를 fragmentation 해줘야 한다. 각각의 패킷들은 분리되어 보내지고, 이때 분리되었지만 원래 하나의 패킷이었음을 알려줘야 한다. 최종 목적지에서 이를 재조립할 때 먼저 identifier를 확인해서 같은 id끼리는 원래 같은 패킷이었음을 확인한다. 분리된 패킷들은 flag를 가지는데, X, D, M 필드를 가진다. X는 사용하지 않으며 D는 'do not' 필드이다. D = 1이면 패킷을 fragment 할 수 없다는 의미이다. M은 More 필드로, M = 1일 때 뒤에 따라오는 패킷이 더 있다는 말이고, M = 0이면 마지막 패킷이라는 것을 뜻한다. 그래서 Fragment offset을 보고 순서대로 조합할 수 있다.

 

TTL(Time to Live)

Hop을 지날 때마다 1씩 줄여주고, 이 값이 0이 되면 버린다. 오류가 발생하면 이 패킷이 네트워크 상에서 떠돌아다니는 것을 방지하기 위함이다. TTL = 0이 되면 ICMP 프로토콜로 오류가 발생했음을 송신측으로 알린다.

 

Upper Layer

말 그대로 상위 계층 정보를 담은 필드로 TCP나 UDP가 저장된다.

 

Header Checksum

헤더에 대한 오류를 검출한다. TTL 값이 hop을 지날 때마다 업데이트되기 때문에 매 라우터마다 checksum을 계산해주어야 한다. 오류가 발생하면 라우터에서는 그 패킷을 버린다. 참고로, transport 계층에서도 오류 검사를 하는데도 Network 계층에서 오류를 검사하는데는 이유가 있다.  먼저 네트워크 계층에서는 IP 헤더만 검사하는 것이다. transport 계층에서는 헤더부터 payload 까지 검사한다. 또, TCP/UDP 계층과 IP 계층은 같은 프로토콜에 속할 필요가 없기 때문이다. TCP/UDP 계층이 없는 데이터를 받을 수도 있고 반대로 IP 계층을 지나지 않는 데이터를 관리할 수도 있기 때문이다.

 

Source IP Address, Destination IP Address 

출발지와 목적지에 대한 32비트 IP 주소를 저장한다. 

 

Options

IP 헤더를 확정해서 필요한 옵션을 기록한다. 보통은 오버헤드를 해결하기 위해서 헤더 옵션은 사용하지 않는다. 그 중에서도 timestamp, Record Route Taken 등을 저장할 수 있다. Record route taken이란 패킷이 라우터를 지날 때 라우터에 대한 정보를 저장해두고 이를 전송한다. option 필드는 헤더 길이가 제한되어 있기 때문에 무한대로 많은 정보를 저장할 수 없다. 또 이 필드에는 source routing 정보를 담아 보낼 수 있는데, 이는 송신측에서 수신측까지의 모든 경로를 저장한 목록을 저장한다. 이를 보고 패킷은 출발지~목적지 경로를 따라 전송된다.

 

 

IP Addressing

• IP Address : 라우터 인터페이스에 대한 32비트 identifier
• interface : 호스트/라우터와 물리적인 링크와의 연결

호스트는 일반적으로 네트워크와 연결되는 링크를 갖는다. 그래서 호스트 IP가 패킷을 보낼 때 이 링크를 통해서 전송한다. 이때 이 호스트와 물리적 링크 사이의 경계를 인터페이스라고 한다. 라우터는 2개 이상의 연결된 링크가 필요한데, 라우터와 어떤 링크 사이의 경계 또한 인터페이스라고 한다. IPv4는 32비트 길이로 2^32개의 주소를 가질 수 있다. 보통은 각 바이트를 십진수로 표기해서 . 으로 구분한다고 해서 dotted decimal 으로 주소를 표기한다. 모든 소스트와 라우터의 인터페이스는 고유한 IP 주소를 갖기 때문에 이를 subnet이 관리한다.

 

일단, IP 주소는 두 부분으로 나눌 수 있다. 네트워크 Id와 Host Id로 나눌 수 있는데, 예를 들어 155.230.80.6에서 네트워크 주소는 155.230까지, Host 주소는 80.6이다.

 

아래 예시를 보자.

이 예시를 보면 한 라우터가 3개의 인터페이스를 가진다. 참고로, 네트워크 사이즈에 따라 주소 형태가 다르다. class 단위로 주소를 부여하는데 첫 비트가 0이면 class A, 10으로 시작하면 class B, 110으로 시작하면 class C이다. 

 

Subnet

IPv4는 32비트이기 때문에 2^32개의 주소를 가지는데, 인터넷 사용자가 늘어나면서 주소가 부족하게 되었다. class 단위로 주소를 부여하다 보니 부족해진 것도 이유다. 그래서 등장한 것이 subnet이다. 클래스 단위로 주소를 부여하지 않고 필요한 만큼만 부여해서 주소를 효율적으로 관리한다. 그래서 subnet은 말그대로 네트워크를 작은 네트워크로 나눠놓은 것이다. 라우터 없이 서로 도달할 수 있도록 하고 IP 주소 관점에서 보면, subnet 부분이 동일한 값을 가지는 인터페이스들이다. 

 

그래서 호스트 id를 사용해서 네트워크 id를 나타내고, 상위 24비트까지가 subnet 마스크이다. 예를 들어 위 그림처럼 223.1.3.1과 223.1.3.2가 같은 subnet으로 묶여있으며 이때 subnet 주소는 223.1.3이고, host id는 각각 1과 2이다. 그리고 223.1.1.0/24에서 /24를 서브넷 마스크라고 한다. 

 

 

CIDR(Classless InterDomain Routing)

위에서 설명한 방식을 CIDR이라고 한다. 주소 공간의 비효율적인 사용으로 인한 주소 공간 부족 문제를 해결할 수 있는 방법으로 나온 것이다. class 대신에 subnet 부분을 만들어서 주소 공간을 효율적으로 사용한다. 32비트 IP 주소는 두 부분으로 나누고 점으로 된 십진수 형태로 변환한다. a.b.c.d/x로 표기한다. 이때 x 비트는 IP 주소의 네트워크 부분을 담당한다. 이를 prefix라고 한다. 이런 경우에는 장비들이 같은 prefix를 공유한다. 외부 네트워크에서 데이터를 보낸다고 하면, prefix만 고려해서 전송한다. 그러면 내부에서 알아서 네트워크 주소로 전송한다. 

 

 

DHCP(Dynamic Host Configuration Protocol)

32bit 주소 공간의 부족 문제를 해결하는 첫 번째 방법이다. 호스트가 새로운 네트워크에 들어가면, 어떻게 IP를 할당 받을까? 시스템 관리자에 요청하여 직접 할당 받거나, 서버로부터 동적 IP를 할당받을 수 있다. 이를 plug & play 방식이라고 한다. 한 기관에서는 ISP로부터 주소 블록을 할당 받고 나서, 개별 주소를 호스트와 라우터 인터페이스에 할당한다. 이때, 호스트가 네크워크 서버로부터 IP 주소를 새롭게 할당받아서 정해진 시간 내에 사용할 수 있게 하는 방식이다. 이때 호스트 IP 주소 뿐만 아니라 서브넷 마스크, 게이트웨이, 로컬 DNS 서버 주소 등도 할당한다. 

 

처음에 client는 네트워크에 접속해도 IP 주소가 없다. IP 주소를 아직 할당 받기 전이기 때문에 broadcast로 많은 DHCP 서버한테 메세지를 보내어 IP를 요청한다. DHCP 서버가 이 메세지를 수신하면, 사용할 수 있는 IP 주소와 함께 자신이 여기 있다는 메세지를 보낸다. 이때도 송신한 client만 보내는게 아니라 broadcast로 전송한다. client는 여러 DHCP에게 메세지를 받은 후에, 그 중에서 가장 적절한 DHCP 서버를 선택해서 request 메세지를 보낸다. 이때도 Broadcast 메세지로 보내게 되는데, 그 이유는 여러 DHCP에게 IP 요청을 했기 때문에 다른 서버들도 client가 어떤 서버를 선택했다라는 것을 알게 해주는 것이다. 마지막으로, client에게 선택받은 서버는 ACK 메세지를 보내어 IP를 할당한다. IP 주소를 사용하는 호스트는 정해진 시간이 지나면 다시 할당을 받거나 새롭게 IP를 할당받는 메커니즘도 있다. 

 

 

NAT(Network Address Translation)

32bit 주소 공간 부족 문제를 해결하는 2번째 방법이다. NAT는 여러 디바이스가 하나의 공인 IP 주소를 공유할 수 있도록 하여 주소 부족 문제를 완화하기 위한 것이다. 즉, 할당받은 IP에 내부 네트워크를 형성해서 외부에서 봤을 때는 마치 하나의 호스트처럼 보이게 된다. 이런 방식은 하나의 IP 주소에 여러 호스트가 있어 주소 공간 부족 문제를 해결할 수 있다. 이 내부 네트워크는 공인되지 않았으므로, 다른 네트워크에서도 같은 주소가 있을 수는 있지만, 외부에서 동작하지 않기 때문에 전혀 문제되지 않는다.

 

내부 네크워크의 호스트가 외부로 데이터를 전송한다고 하자. 그러면 외부에서는 내부 네트워크의 존재를 모르기 때문에 Source IP 주소를 10.0.0.1로 설정하면 안된다. 그래서 내부 네트워크와 외부 네트워크를 연결하는 NAT 장비가 중계한다.

 

먼저, 내부 네트워크인 10.0.0.1이 128.119.40.186에 데이터를 전송한다고 하자. 그러면, NAT table을 통해 Source IP address가 138.76.29.7로 바뀌어 외부 네트워크로 나간다. 128.119.40.186에서 응답이 들어온다면, 또 NAT table을 통해 destination 주소가 10.0.0.1로 바뀌어 호스트에게 정확하게 도착한다.

 

이러한 방법은 외부 네트워크에서 내부 네트워크의 호스트로 데이터를 전송할 수 없다. NAT 장비가 어느 호스트로 보내야 할 지 결정할 수 없기 때문이다.

 

 

IPv6

주소 공간 부족 문제를 해결하기 위해서 IP 버전이 업그레이드 되었다. IPv4에 비해서 무엇이 달라졌는데 데이터그램 포맷을 통해 알아보자.

 

IPv6 Datagram Format

• 주소 크기 확장 : 기존의 IPv4는 32bit 주소 체계를 가지고 있어 2^32개의 주소를 할당할 수 있었다. IPv6는 128bit로 2^128개의 주소를 할당할 수 있다. 이때 anycast address라는 새로운 주소 형태를 도입했다.
• 간소화된 헤더 : option이 존재해 가변길이 헤더를 가지는 IPv4에 비해서 IPv6은 40byte의 고정된 크기의 헤더 길이를 가지고 있어 라우터의 처리 속도를 향상시켰다. IPv4 헤더에 포함되었던 내용들은 옵션에 기록한다.
• 호스트 주소 자동 설정 : IPv4는 시스템 관리자에게 주소 할당을 직접 받아야 했지만 IPv6는 DHCP 방식으로 IP 주소를 자동으로 할당받을 수 있다. 이러한 방식을 plug & play 방식이라고 한다. 따라서 네트워크에 접속하자 마자 바로 IP를 할당 받을 수 있다.
• flow field: 데이터그램의 특별한 처리를 요청하는 필드로 IPv4의 Type of Service와 유사하다.

IPv6에서 사라진 필드

• Option 필드 : 표준 IP 헤더로 인정하지 않는다. 다음 IP 헤더를 가리키는 용도로만 사용한다. 옵션 필드가 제거되었기 때문에 표준에서는 고정길이 40byte 헤더를 갖게 되었다.
• Checksum 삭제 : 전송 계층과 링크 계층에서 이미 패킷 checksum을 계산하기 때문에 생략해도 될 것이라 판단해서 삭제한 것이다. 따라서 라우터에서 처리하는 속도가 향상되었다.
• Fragmentation/reassembly 없음 : IPv6의 전달 과정에서 패킷의 분할과 재조합이 발생하지 않는다. 패킷의 길이가 너무 길다면, 출발지에서만 분리되고, 도착지에서만 재조합된다. 따라서 각각의 패킷에 명시할 필요가 없고, 만약에 전달 중에 패킷의 길이가 너무 길어서 줄여야 한다면, 패킷을 버린다. 그리고 ICMP을 통해서 출발지로 오류 메세지를 전송하는 매커니즘이다.

 

IPv6에서 IPv4로의 변환

IPv6 주소를 사용한다고 해서 모든 라우터들이 한꺼번에 업그레이드되는 것은 아니다. 그래서 IPv4와 IPv6를 혼용할 수 있도록 하는 여러가지 방법이 있다. 그중에서 Tunneling 방법이 있다. 이는 IPv6 데이터그램을 payload로, IPv4가 IPV6를 감싸고 있는 형태로 데이터를 전송한다.