Chapter4. 네트워크 계층: 데이터 평면(3.1-3.2)

4.3 인터넷 프로토콜(IP): IPv4, 주소체계, IPv6등

이번 절에서는 인터넷과 IP에서 네트워크 계층의 핵심적인 측면에 초점을 맞춤.

현재 사용 중인 IP는 두 가지 버전이 있는데, IPv4와 IPv6이 있음.

4.3.1 IPv4 데이터그램 포맷

인터넷 네트워크 계층 패킷 → 데이터그램

• 버전 번호
  • 4비트로 데이터그램의 IP프로토콜 버전을 명시함.
  • 라우터는 버전 번호를 확인하여 데이터그램의 나머지 부분을 어떻게 해석할지 결정.
• 헤더 길이
  • IPv4 데이터그램은 헤더에 가변 길이의 옵션을 포함 → 네 비트로 IP 데이터그램에서 실제 페이로드가 시작하는 곳을 결정함.
  • 대부분의 IPv4 데이터그램은 옵션을 포함하지 않으므로 대체로 IPv4 데이터그램 헤더는 20바이트임.
• 서비스 타입(서비스 타입 비트 → TOS)
  • 각각 다른 유형의 IP 데이터그램을 구별함.
  • ex. 실시간 데이터그램과 비실시간 트래픽을 구분하는 데 유용함.
  • TOS비트 중 2개는 명시적 혼잡 알림에 사용됨.
• 데이터그램 길이
  • 최대 크기의 이더넷 프레임의 (페이로드) 필드에 IP 데이터그램이 정착될 수 있음.
• 식별자, 플래그, 단편화 오프셋
  • 위의 세 필드는 IP 단편화와 관련이 있음.
  • 큰 데이터그램이 여러 개의 작은 IP 데이터그램으로 분할된 다음 목적지로 독립적으로 전달되며, 여기서 페이로드 데이터가 최종 호스트의 트랜스포트 계층에 전달되기 전에 다시 모이게 됨.
  • IPv6는 단편화를 허용하지 않음.
    • 단편화란?
• TTL(time-to-live)
  • 네트워크에서 데이터그램이 무한히 순환하지 않도록 함. (라우팅 루프)
  • 해당 필드값은 라우터가 데이터그램을 처리할 때마다 감소함.
  • 필드가 0이 되면 라우터가 데이터그램을 폐기함.
• 프로토콜
  • 일반적으로 IP 데이터그램이 최종 목적지에 도착했을 때 이용됨.
  • IP 데이터그램에서 데이터 부분이 전달될 목적지의 트랜스포트 계층의 특정 프로토콜을 명시함.
  • IP 데이터그램에서 프로토콜 번호의 역할은 트랜스포트 계층 세그먼트에서 포트 번호 필드의 역할과 유사함.
  • 포트 번호가 트랜스포트 계층과 애플리케이션 계층을 함께 묶는 역할 ⇒ 프로토콜 번호는 네트워크 계층과 틑랜스포트 계층을 엮는 역할
  • • 링크계층 프레임이 링크 계층과 네트워크 계층을 묶는 특별한 필드를 갖고 있음.
• 헤더 체크섬
  • 라우터가 수신한 IP 데이터그램의 비트 오류를 탐지하는데 도움을 줌.
  • 헤더에서 각 2바이트의 수로 처리하고 이 1의 보수를 합산하여 계산한 것.
  • 라우터는 수신한 각 IP 데이터그램마다 헤더 체크섬을 계산하고 이 값과 데이터그램 헤더의 체크섬이 다르면 오류 상태임을 감지함.
  • 라우터는 보통 오류가 검출된 데이터그램을 폐기함.
  • TTL 필드와 옵션 필드의 값은 변경되므로 체크섬은 각 라우터에서 재계산되고 저장되어야 함.
  • TCP/IP 는 트랜스포트 계층과 네트워크 계층에서 오류 검사를 수행하는가?
    • IP 헤더만 IP 계층에서 체크섬을 수행하지만 TCP/UDP 체크섬은 전체 TCP/UDP 세그먼트를 계산함.
    • TCP/UDP와 IP는 동일한 프로토콜 스택에 속할 필요가 없음.
    • 원리상 TCP는 IP가 아닌 다른 네트워크 프로토콜 위에서 운영될 수 있고, IP는 TCP/UDP로 전달되지 않는 데이터를 전달할 수 있음.
• 출발지와 목적지 IP 주소
  • 출발지가 데이터그램을 생성할 때, 자신의 IP 주소를 출발지 IP 주소 필드에 삽입하고 목적지 IP 주소를 목적지 IP 주소 필드에 삽입함.
  • 출발지 호스트는 DNS 검색을 통해 목적지 주소를 결정함.
• 옵션
  • 해당 필드는 IP 헤더를 확장함.
  • 데이터그램 헤더가 가변 길이로 데이터 필드 시작점을 초기에 결정할 수 없어 옵션은 문제를 복잡하게 만듬.
  • 일부 데이터그램은 옵션 처리 유무에 따라서 라우터에서 IP 데이터그램을 처리하는 데 필요한 시간이 크게 달라짐.
• 데이터(페이로드)
  • 데이터그램이 존재하는 이유이자 가장 중요한 마지막 필드.
  • 대부분, IP 데이터그램의 데이터 필드는 목적지에 전달하기 위해 트랜스포트 계층 세그먼트(TCP or UDP)를 포함하지만 ICMP 메시지 같은 유형의 데이터를 담기도 함.

IP 데이터그램은 총 20바이트의 헤더(옵션은 없다고 가정)를 갖음.

4.3.3 IPv4 주소체계

IP 주소체계를 살펴보기 전, 호스트와 라우터가 인터넷에 연결되는 방식에 관한 단어를 정의.

호스트는 일반적으로 네트워크와 연결되는 하나의 링크를 갖는데, 호스트 IP가 데이터그램을 보낼 때 이 링크를 통해 데이터링크를 보냄. 호스트와 물리적 링크 사이의 경계를 인터페이스라고 부름.

라우터와 인터페이스를 고려해보면, 라우터의 작업은 한 링크로부터 데이터그램을 수신하여 다른 링크로 전달하는 것이므로 라우터는 2개 이상의 연결된 링크가 필요함. 라우터와 이런 링크 사이의 경계 또한 인터페이스라 하는데, 각 링크마다 하나의 인터페이스를 갖고 하나의 라우터는 여러 개의 인터페이스를 갖음.

모든 호스트와 라우터는 IP 데이터그램 송수신이 가능하므로 IP는 각 호스트와 라우터 인터페이스가 IP 주소를 갖도록 요구함. ⇒ 기술면에서 IP 주소는 인터페이스를 포함하는 호스트 라우터보다는 인터페이스와 관련이 있음.

각 IP 주소는 32비트 길이. 주소의 각 바이트를 십진수로 표현하고 주소의 다른 바이트와 점으로 구분하는 십진 표기법을 사용함.

모든 호스트와 라우터의 각 인터페이스는 고유한 IP주소를 갖음. 이러한 주소는 마음대로 선택할 수 없으며, 인터페이스의 IP 주소 일부는 연결된 서브넷이 결정할 것.

아래의 그림은 IP 주소체계와 인터페이스를 보여주는 예인데, 3개의 인터페이스를 갖는 하나의 라우터는 7개의 호스트를 연결함. 호스트와 라우터 인터페이스에 할당된 IP 주소를 잘 살펴보면, 왼쪽 3개의 호스트와 연결된 라우터 인터페이스는 모두 [223.1.1.xxx](http://223.1.1.xxx) 형식의 IP 주소를 갖고있음. 즉, 동일한 왼쪽 24비트를 사용함.

또한 4개의 인터페이스가 중계하는 라우터 없이 하나의 네트워크에 서로 연결되어 있음.

이 네트워크는 이더넷 LAN으로 상호연결되고 이 경우 인터페이스는 이더넷 허브나 이더넷 스위치 또는 무선 AP로 상호연결됨.

IP 용어로 세 호스트들의 인터페이스들과 하나의 라우터 인터페이스로 연결된 네트워크는 서브넷을 구성한다고 말함. IP 주소체계는 이 서브넷에 223.1.1.0/24라는 주소를 할당하는데, 여기서 /24는 서브넷 마스크라 부르는데, 32비트의 주소의 왼쪽 24비트가 서브넷 주소라는 것을 가리킴.

서브넷 223.1.1.0/24는 세 호스트 인터페이스(223.1.1.1, 223.1.1.2, 223.1.1.3)와 하나의 라우터 인터페이스 (223.1.1.4)를 구성함.

위의 그림에 2개의 서브넷(223.1.2.0/24, 223.1.3.0/24 네트워크)이 있음.

위의 그림은 그림 4.18에 나타낸 세 IP 서브넷을 보여줌.

3개의 라우터가 점대점 링크로 연결된 아래의 그림을 보자.

각 라우터는 각 점대점 링크를 위해 2개, 두 호스트를 직접 연결하는 브로드캐스트 링크를 위해 1개, 모두 3개의 인터페이스를 갖음. 여기에는 3개의 서브넷 (223.1.1.0/24, 223.1.2.0/24, 223.1.3.0/24)은 그림 4.18의 서브넷과 유사하지만 세 서브넷 라우터 R1, R2를 연결하는 인터페이스용으로 223.1.9.0/24 서브넷, 그리고 R2와 R3를 연결하는 인터페이스용 223.1.8.0/24 서브넷, 그리고 R1과 R3를 연결하는 인터페이스용 223.1.7.0/24 서브넷이 추가되었음.

서브넷을 결정하려면 먼저 호스트나 라우터에서 각 인터페이스를 분리하고 고립된 네트워크를 만든다. 이 고립된 네트워크의 종단점은 인터페이스의 끝이 된다. 이렇게 고립된 네트워크 각각을 서브넷이라고 부른다.

그림 4.20의 연결된 시스템은 6개의 고립된 서브넷을 얻게됨.

다수의 이더넷 세그먼트와 종단 간의 링크를 갖는 기관은 한 서브넷에서 모든 장비가 같은 서브넷 주소를 갖는 그런 서브넷을 여러 개 가질 수 있음.

인터넷 주소 할당 방식에 CIDR 라는 것이 있는데, 이는 서브넷 주소체계 표기를 일반화하고 있음. 서브넷 주소체계로서, 32비트 IP 주소는 두 부분으로 나누고, 이것은 다시 점으로 된 십진수 형태의 a.b.c.d/x를 가지며, 여기서 x는 주소 첫 부분의 비트 수임.

최상위 비트를 의미하는 x는 IP 주소의 네트워크 부분을 구성함. 이를 해당 주소의 프리픽스 또는 네트워크 프리픽스라고 부름. 한 기관은 통상 연속적인 주소의 블록을 할당받게됨. 이 경우에 기관 장비들의 IP 주소는 공통 프리픽스를 공유함.

외부 기관의 라우터는 목적지 주소가 내부 기관인 데이터그램을 전달할 때, 단지 앞의 x비트들만 고려함

a.b.c.d/x 형태의 한 엔트리만으로 기관 목적지로 패킷을 전달하는 데 충분하므로, 이런 라우터들에서 포워딩 테이블의 크기를 상당히 줄여줌.

주소의 나머지 32-x 비트들은 기관 내부에 같은 네트워크 프리픽스를 갖는 모든 장비를 구별한다고 보면 됨. 이 비트들은 기관 내부와 라우터에서 패킷을 전달할 때 사용되는 것임.

이 하위 비트들은 추가 서브넷 구조를 가질 수도 있음.

예를 들어, CIDR식 주소 a.b.c.d/21의 첫 21비트들은 기관의 네트워크 프리픽스를 나타내고 이 기관의 모든 장비의 IP 주소에 공통이라고 가정. 나머지 11비트들은 기관 내부의 특정 호스트들을 식별함. 기관의 내부 구조가 이 최하위 11비트들 중 일부를 기관 내부의 서브넷을 위해 사용할 수도 있음. (ex. a.b.c.d/24는 기관 내부의 특정 서브넷을 나타낼 수도 있음.)

CIDR가 채택되기 전에는 IP 주소의 네트워크 부분을 8, 16, 24비트로 제한했었는데 이러한 주소체계는 클래스 주소체계로 알려졌음.

but, IP 주소의 서브넷 부분이 정확히 1, 2, 3 바이트여야 한다는 요구사항은 중소형 크기의 네트워크로 급속히 증가하는 기관의 수를 지원하기엔 문제가 있었음.

IP 주소의 또 다른 형태인 브로드캐스트 주소 255.255.255.255가 있음. 호스트가 목적지 주소가 255.255.255.255인 데이터그램을 보내면, 이 메시지는 같은 서브넷에 있는 모든 호스트들에게 전달됨. 라우터는 선택적으로 이웃 서브넷에 메시지를 전달함. (일반적으로 잘 사용되지는 않음.)

호스트와 서브넷이 처음에 어떻게 자신의 주소를 인식하는지 알 필요가 있다!

주소 블록 획득

기관의 서브넷에서 사용하기 위한 IP 주소 블록을 얻기 위해, 네트워크 관리자는 먼저 이미 할당받은 주소의 큰 블록에서 주소를 제공하는 ISP와 접촉해야 함.

ex. ISP는 주소 블록 200.23.16.0/20을 할당받았다고 하자. ISP는 이 주소 블록을 아래의 그림처럼 같은 크기의 작은 주소 블록 8개로 나누고, 이것으로 8개의 조직을 지원할 수 있음.

ISP로부터 주소를 획득하는 것은 주소 블록을 얻는 한 방법이지만 다른 방법도 있음. ISP도 주소 블록을 얻기 위한 방법이 있어야 함.

IP주소 공간을 관리하고 ISP와 다른 조직에 주소 블록을 할당하는 최상위 국제기관이 존재함. 이러한 IP 주소는 ICANN을 기반으로 관리함. ICANN은 IP주소 할당과 DNS 루트 서버 관리임.

호스트 주소 획득: 동적 호스트 구성 프로토콜

한 기관은 ISP로부터 주소 블록을 획득하여, 개별 IP 주소를 기관 내부의 호스트와 라우터 인터페이스에 할당함. 라우터 인터페이스 주소에 대해, 시스템 관리자는 라우터 안에 IP 주소를 할당함.

호스트에 IP주소를 할당하는 것은 일반적으로 동적 호스트 구성 프로토콜(DHCP) 를 더 많이 사용함.

DHCP는 호스트가 IP주소를 자동으로 얻을 수 있게 함. 네트워크 관리자는 해당 호스트가 네트워크에 접속하고자 할 때마다 동일한 IP 주소를 받도록 하거나, 다른 임시 IP 주소를 할당하도록, DHCP를 설정함.

DHCP는 호스트 IP 주소의 할당뿐만 아니라, 서브넷 마스크, 첫 번째 홉 라우터 주소나 로컬 DNS 서버 주소 같은 추가 정보를 얻게 해줌.

자동으로 호스트와 연결해주는 DHCP의 능력 때문에 플러그 앤 플레이 프로토콜 또는 제로 구성 프로토콜 이라고도 함.

많은 사용자가 이동하고, 주소들이 제한된 시간 동안에만 필요할 경우 DHCP는 적합함.

DHCP는 클라이언트-서버 프로토콜임. 클라이언트는 일반적으로 IP 주소를 포함하며 네트워크 설정을 위한 정보를 얻고자 새롭게 도착한 호스트. 가장 간단한 경우, 각 서브넷은 DHCP 서버를 가질 것임. 만약 서버가 현재 서브넷에 없다면, 해당 네트워크에 대한 DHCP 서버 주소를 알려줄 DHCP 연결 에이전트(일반적으로 라우터)가 필요함.

위의 그림은 223.1.2/24에 연결된 DHCP 서버와 서브넷 223.1.1/24와 223.1.3/24에 접속될 클라이언트가 도착할 경우 연결 에이전트로 서비스할 라우터.

이후 논의에서는 DHCP 서버가 서브넷에서 이용 가능하다고 가정함.

위의 그림은 새로운 호스트가 도착할 경우, 그림 4.23에서 설정된 네트워크상에서 수행될 DHCP 프로토콜 4단계의 과정을 보여주는 것임. yiaddr은 새롭게 도착한 클라이언트에 할당될 주소를 나타냄.

• DHCP 서버 발견
  • 새롭게 도착한 호스트는 상호작용할 DHCP를 발견함.
  • 이것은 DHCP 발견 메시지를 사용하여 수행되며, 클라이언트는 포트 67번으로 UDP 패킷을 보내고, UDP 패킷은 IP 데이터그램으로 캡슐화됨.
  • but, 데이터그램을 누구에게 보낼지 모르는 상황.
  • DHCP 클라이언트는 DHCP 발견 메시지를 포함하는 IP 데이터그램을 생성하는데, 이 메시지 내의 목적지 IP 주소를 브로드캐스트 IP 주소 255.255.255.255로 설정하고 출발지 주소는 0.0.0.0으로 설정함.
  • DHCP 클라이언트는 링크 계층으로 IP 데이터그램을 보내며 해당 프레임은 서브넷에 연결된 모든 노드로 브로드캐스트됨.
• DHCP 서버 제공
  • DHCP 발견 메시지를 받은 DHCP 서버는 DHCP 제공 메시지를 클라이언트로 응답함. → 다시 IP 브로드캐스트 주소 255.255.255.255를 사용하여 서브넷의 모든 노드로 이 메시지를 브로드캐스트함.
  • 서브넷에는 여러 DHCP 서버가 존재하기 때문에, 클라이언트는 여러 DHCP 제공 메시지로부터 가장 최적의 위치에 있는 DHCP 서버를 선택함.
  • 각 서버 제공 메시지에는 수신된 발견 메시지의 트랜잭션 ID, 클라이언트에 제공된 IP 주소, 네트워크 마스크, IP 주소 임대 기간을 포함함.
• DHCP 요청
  • 클라이언트는 하나 또는 그 이상의 서버 제공자 중에서 선택함.
  • 선택된 제공자에게 파라미터 설정으로 되돌아오는 DHCP 요청 메시지로 응답.
• DHCP ACK
  • 서버는 DHCP 요청 메시지에 대해 요청된 파라미터를 확인하는 DHCP ACK 메시지로 응답함.

클라이언트가 DHCP ACK 메시지를 받으면, 상호작용은 종료되고 클라이언트는 DHCP 할당 IP 주소를 임대 기간동안 사용 가능함. 기간 만료 후에도 사용할 경우에 대비하여 IP 주소 임대를 갱신할 수 있는 메커니즘을 제공함.

이동성 측면에서 볼 때, DHCP는 큰 결점 하나가 있는데, 노드가 새로운 서브넷에 연결하고자 할 때마다 새로운 IP 주소를 DHCP로부터 얻기 때문에, 이동 노드가 서브넷 사이를 이동할 때 원격 애플리케이션에 대한 TCP 연결은 유지될 수 없음.