전송계층에서 TCP 혹은 UDP 헤더를 붙여 만들어진 패킷에 IP 헤더를 붙여 IP 패킷을 생성
패킷은 헤더에 명시된 IP 주소를 기반으로 목적지로 전송된다.
IP 자체는 비연결형 프로토콜이며 신뢰성있는 전송을 보장하지 않는다.(이는 전송계층에서 담당)
2. IP 헤더(IPv6)
출처:https://en.wikipedia.org/wiki/IPv4
Version
현재 사용하는 IP의 버전
IHL(IP Header Length)
IP 헤더의 길이(데이터 포함 X)
TOS(Type of Service)
서비스의 우선순위를 표시하기 위한 영역
Total Length
데이터를 포함한 IP패킷 전체의 길이
Identification / Flags / Fragment Offset
라우터의 전송가능한 최대 패킷 크기(MTU)가 IP 패킷보다 작아 패킷이 쪼개질 경우 쪼개진 패킷을 다시 재조립하기 위해 필요한 정보를 저장하기 위한 영역
Identification(16bit) : 어느 패킷의 프래그먼트인지 나타내기 위한 영역
Flags(3bit) : 패킷 분할 정보를 나타내기 위한 영역. 예를들어 마지막 비트는 뒤에 다른 프래그먼트가 더 있는지 표시되기 위해 사용된다.
Offset(15bit) : 각 프래그먼트의 원본 데이터에서의 인덱스를 나타내는 영역
TTL(Time To Live)
초기 설정한 값에서 포워딩을 거칠 때마다 1씩 감소
패킷에 수명을 주어 무한루프에 빠진 패킷 등이 일정 횟수의 포워딩을 거치면 사라지도록 함
Protocol(Upper Layer)
상위 계층에서 사용될 프로토콜을 명시(TCP/UDP 등)
Header Checksum
ip 헤더의 체크섬을 저장 - 최소한의 에러검출
Source/Destination IP Address
출발지, 목적지 IP주소
Options
추가적인 처리 옵션을 정의하기 위한 영역
없을 수도 있으며 최대 40바이트까지 사용 가능
3. IP 주소
8비트로 표현되는 정수 4개(32비트)로 표현되는 주소체계 => IPv6의 경우 총 128비트로 주소를 표현한다. 즉, 2 ^ 128 개의 독립적인 주소를 표현할 수 있다.
IP 주소는 엄밀히 말해 특정 호스트를 가리키는 주소가 아닌 네트워크 인터페이스를 가리키는 주소 => 라우터와 같이 다수의 인터페이스를 가지는(다수의 IP주소를 가지는) 장비도 존재한다.
IP의 분배
단순히 IP 하나하나를 호스트에게 배분하는 방식을 사용할 경우 포워딩 테이블의 크기가 너무 커지며 포워딩에 걸리는 시간도 너무 길어진다.
IP 계층화
Network ID 부분과 Host ID 부분을 분리
ex) 12.34.158.0/24
상위 24비트(12.34.158) 까지는 네트워크 ID
나머지 8비트(0) 까지는 호스트 ID
같은 네트워크에 속하는 호스트들을 동일한 IP prefix로 묶을 수 있게 된다 => 포워딩 테이블을 보다 간단하게 표현하여 효율적인 포워딩을 가능하게 한다.
새 호스트에 IP주소를 할당하는 작업도 간단해짐
과거에는 네트워크 ID를 부여받는 기관의 규모에 따라 네트워크 ID 비트수를 조정
A클래스 - 상위 8비트를 네트워크 ID로 사용
B클래스 - 상위 16비트를 네트워크 ID로 사용
C클래스 - 상위 24비트를 네트워크 ID로 사용
현재는 서브네팅을 사용하여 유동적으로 prefix를 조절
서브넷 마스크(Subnet Mask)
네트워크 ID가 어디까지인지 컴퓨터가 이해할 수 있도록 표현하는 방식
ex) 125.23.87.0 이라는 네트워크 ID를 부여받았을 때, 각각 30개의 호스트를 가지는 8개의 서브넷으로 분리하려면 네트워크 ID인 24비트까지의 서브넷마스크는 모두 1, 그 이하로는 8개의 서브넷을 사용하기 위해 3개의 비트를 1로, 나머지를 0으로 하면 0인 부분이 5비트가 되어 32개의 주소를 나타낼 수 있게된다.
만약 125.23.87.0 에 서브넷마스크가 255.255.255.192라면
서브넷의 갯수는 최대 4개이다.
각 서브넷의 호스트 범위는 0~63, 64~127, 128~191, 192~255 가 된다.
이 중 세 번째 서브넷인 128~191 에서 대표주소는 125.23.87.128이며 브로드캐스트 주소는 125.23.87.191이 된다.
NAT(Network Address Translation)
20년 전에도 이미 IPv4가 지원하는 2 ^ 32 개의 주소만으론 부족할 것으로 예상하여 IPv6를 만들었지만 정작 현재까지도 사용중인것은 여전히 IPv4 이다
IPv6로의 이전을 위해서는 기존에 사용하던 모든 네트워크 장비를 교체해야하는데, 이는 아직까지는 현실적으로 어려움이 따름
결과적으로 IPv4를 그대로 사용하면서도 표현 가능한 주소의 갯수를 늘리기 위해 NAT(Network Address Translation)를 사용
NAT의 방식
로컬 네트워크에서 그 네트워크 내부에서만 유일성을 가지는 IP 주소를 분배
네트워크 내부 호스트가 외부 호스트에게 데이터를 전송할 경우 내부 호스트의 IP주소를 전 세계적으로도 유일한 게이트웨이 주소로 변경해주고 외부에서 내부의 호스트에게 데이터를 전송할 경우 내부 IP주소로 변환하여 내부 호스트에게 전달해준다.
기본적으로는 출발지 IP주소(게이트웨이 주소)와 도착지 IP주소를 통해 내부 IP를 특정하지만 이 방식으로는 다수의 내부 호스트가 같은 목적지와 통신할 경우 구분이 불가능해진다. 이를 해결하기 위해 추가적으로 포트를 구성하여 패킷을 구분하는 PAT 혹은 NAPT 방식을 사용한다.
NAT 테이블에 기록되는 것은 내부에서 패킷을 전송할 때이기 때문에 클라이언트로써는 문제가 없지만 상대의 요청을 기다려야하는 서버로서는 정상적으로 동작하기 어렵다. NAT 테이블에 직접 변환정보를 기재하여 서버로서 동작할 수 있게 하는 방법도 있지만 일반 사용자가 할 수 있는 작업은 아니다.
NAT의 또다른 문제는 계층화된 네트워크 구조를 어기고있다는 점이다. 네트워크 계층에서 동작하는 장비인 NAT 라우터가 IP 패킷의 데이터부분(TCP헤더의 포트)을 인지하고 수정까지 하는 규칙위반을 하고있다. (대부분의 사용자는 서버 역할을 할 경우가 없기 때문에 문제를 크게 인지하지 못한다.)
DHCP(Dynamic Host Configuration Protocol)
DHCP 서버가 네트워크에 연결된 호스트에게 자동으로 IP주소를 대여해주는 방식
절차
DHCP 클라이언트는 네트워크에 연결하기 위해 네트워크 내에서 브로드캐스트(255.255.255.255)로 DHCP 서버에게 IP 주소를 요청하는 패킷을 전송(discover)
DHCP 서버는 요청에 대한 응답으로 대여해줄 IP 주소를 담은 패킷을 전송(offer)
DHCP 클라이언트는 요청에 응답해준 DHCP 서버중 하나를 선택하여 해당 서버를 선택했음을 알리는 패킷을 브로드캐스트로 전송한다.(request) 이 때, 브로드캐스트를 사용하는 이유는 선택받지 못한 DHCP 서버가 자신의 요청을 더이상 신경 쓸 필요가 없도록 해주기 위해서이다.
선택받은 DHCP 서버는 request 패킷에 대해 ack 패킷을 보내고 프로토콜이 완료된다. 이후부터 클라이언트측은 대여받은 IP를 통해 통신이 가능해진다.
이 과정을 통해 네트워크에 연결된 호스트는 자신과 연결된 DNS 서버와 게이트웨이 라우터의 IP주소를 알게되고 이를 기반으로 포워딩 테이블을 생성하게 된다.
3. 라우터(Router)
네트워크 계층의 핵심 장비
IP 패킷들은 출발지와 목적지 사이를 연결하는 다수의 라우터를 거쳐 전송된다.
포워딩(Forwarding)
라우터의 가장 기본적인 기능
라우터가 가진 포워딩 테이블에 따라 목적지 주소에 매칭되는 방향으로 패킷을 전송
목적지 주소 하나하나에 매칭되는 방향을 따로 관리하는 것을 비효율적 => 엔트리를 주소의 범위 형태로 구성하여 목적지 주소와 가장 많이 일치하는 엔트리와 매칭
라우팅(Routing)
포워딩을 위한 포워딩 테이블을 생성하는 작업
목적지 주소까지의 모든 경로 중 최적의 경로를 탐색
라우팅 결과 만들어진 포워딩 테이블은 라우터의 입력 포트에 각각 저장되며 라우터에 도착한 패킷들의 포워딩은 이를 이용하여 각 포트에서 병렬적으로 수행된다.
4. 라우팅 알고리즘
연결 상태(Link State) 알고리즘
라우터간의 연결 상태정보를 모든 라우터에 전달하여 최단경로를 탐색하는 알고리즘
데이크스트라(Dijkstra)의 최단경로 알고리즘 사용
라우팅 정보 변경될 경우에만 변경정보를 브로드캐스팅으로 전달
최단경로를 구하기 위해 전체 링크의 상태를 알고있어야하기 때문에 추가적인 메모리가 필요
OSPF, IS-IS 등의 프로토콜이 이 알고리즘을 사용
대규모 네트워크에 적합
거리 벡터(Distance Vector) 알고리즘
최단경로 탐색을 재귀적으로 수행 => 브로드캐스팅이 아닌 이웃한 라우터와의 통신만으로 네트워크의 상태를 파악
벨만 포드(Bellman-Ford Algorithm)의 최단경로 알고리즘 사용
라우팅 정보 변경의 전달이 주기적으로 이루어짐
즉각적으로 발생하지 않기 때문에 잘못된 정보로 경로를 계산하게 될 수 있음
변화가 없어도 주기적으로 통신이 발생하기에 트래픽을 낭비
count to infinity 문제
인접한 노드의 목적지까지의 거리를 토대로 목적지까지의 최단경로를 계산
그런데 인접한 노드의 최단경로에 자기자신이 포함될경우 문제가 발생(역류)
인접한 노드 x에 의존하는 최단경로값을 노드 x에 넘겨줄 때는 무한값을 넘겨주는 것으로 역류를 미연에 방지할 수 있음
RIP, IGRP 등의 프로토콜이 이 알고리즘을 사용
소규모 네트워크에 적합
5. AS(Autonomous System) - 자율시스템
통일된 라우팅 프로토콜을 사용하고 동일한 관리자에 의해 관리되는 독립된 네트워크 영역
해당 네트워크에 속한 라우터와 서브 네트워크들의 집합
넓게 보면 ISP(Internet Service Provider)를 말하기도 한다.
필요성
전 세계의 라우터를 대상으로 라우팅 알고리즘을 실행하기에는 그 수가 너무 많음
계층화를 통해 라우팅의 규모를 분할 - 보다 효율적인 라우팅
라우팅 알고리즘을 AS별로 독립적으로 적용
AS 단위의 보안 유지
고장 및 오류를 AS단위로 관리 가능
AS 라우팅 프로토콜
IGP(Interior Gateway Protocol)
AS 내부의 라우터간의 라우팅
RIP, IGRP, EIGRP, OSPF, IS-IS 등 일반적으로 말하는 라우팅 알고리즘은 IGP를 의미
EGP(Exterior Gateway Protocol)
서로 다른 AS 간의 라우팅
BGP(Border Gateway Protocol)
서로 다른 AS간에 라우팅 경로를 설정하기 위해 AS 외곽의 라우터끼리 IP주소 정보를 교환