[컴퓨터 네트워크] 27. Network Layer (3) : IP

IP - Internet Protocol

IP는 인터넷에서 제일 중요한 프로토콜이다.

IP가 없으면 인터넷 동작을 할 수가 없기 때문이다

내가 아무리 엔드시스템에서 기가 막힌 인터넷 어플리케이션을 만들었다고 하더라도, IP가 없으면 (IP에 의존하지 않으면) 상대방 컴퓨터와 통신을 할 방법이 아예없다.

 

반대로, 데이터링크 계층에 새로운 기술을 개발했고, 이 기술이 이더넷보다 훨씬 훌륭하다고 생각한다고 해보자.

그런데 이 기술을 이용해서 돈을 벌려면 이 기술을 사용한 장치가 인터넷에 연결이 되어야 한다.

인터넷은 플랫폼이기 때문이다.

따라서 IP가 없어서 대문자 I의 인터넷에 연결될 수 없다면 이 기술은 무용지물이다.

IP는 여러 데이터링크 계층 기술과 인터넷이 붙을 수있도록 해주는 접착제 역할을 해준다.

 

따라서 IP는 네트워크 계층의 제일 중요한 프로토콜이다.

IP에는 데이터 그램의 포맷, IP 패킷이 목적지에 어떻게 전달되는지 등이 정의되어 있다.

 

또 Path-Selection algorithms 도 네트워크 계층에 속한다. (이 알고리즘은 분산 알고리즘이다.)

각각의 경로 선택 알고리즘은 OSPF, BGP와 같은 인터넷 표준 라우팅 프로토콜과 SDN controller에 구현되어있다.

이 라우터 프로토콜들은 경로 선택 알고리즘을 사용해서 각 라우터에 포워딩 테이블을 만들어서 이 포워딩 테이블을 기반으로 패킷을 적절한 다음 장소(라우터 또는 목적지)로 포워딩시킨다.

 

SDN은 라우팅 프로토콜 뿐만 아니라 새로운 알고리즘도 필요하다면 즉각 도입해서 그 방식으로 포워딩 테이블을 가질 수 있도록 허용하는, 융통성을 부여하는 방식이다.

 

IPv4 Header

 

IP는 네트워크 계층의 프로토콜이므로, 여기에는 네트워크 계층에서 사용하는 주소 체계가 들어가야 한다.

그게 source IP address, destination IP address 부분이다.

 

[첫번째 줄]

ver : IP 프로토콜의 버전을 가리킨다. 지금보는 헤더는 version 4 이므로 4가 들어간다.

header length : 헤더의 길이가 들어간다. TCP 처럼 고정되어 있지 않고, IP도 option이 들어갈 수 있어서 헤더의 길이가 가변이다. 그래서 IP를 사용할 때 옵션은 가급적 쓰지 말라고 한다. 옵션 처리를 위해서 라우터가 오버헤드를 감수해야 하기 때문이다. 만약 옵션이 없다면 헤더의 크기는 20byte 이다.

TCP도 옵션이 없으면 20byte 이기 때문에, IP를 사용해서 TCP 세그먼트를 인캡슐레이션한다면, 헤더 오버헤드만 총 40byte가 된다.

type of service (tos) : 서비스 구분을 위해서 만든 필드다. (서비스 구분은 오래전부터 인터넷에서 연구가 되었던 분야다. 인터넷에서 내 트래픽이 특별 취급을 받고 싶다! 와 같은 특별한 요구사항이 있는 패킷에 대해 어떤 서비스를 제공할지 결정하는데 필요한 필드였다. 즉, 트래픽 구분용도이다.) 하지만 지금은 전혀 사용되지 않는다. bandwidth가 커지면서 서비스를 구분해서 제공할 필요가 없어졌기 때문이다. 따라서 tos는 필요성이 전혀 없다고는 못해도, 굳이 구분해서 뭔가를 보내는 일은 없다.

 

length : 데이터의 크기를 나타낸다. 참고로 TCP 세그먼트에는 길이 필드가 없다.

그래서 이 필드를 이용하면 간접적으로 TCP 세그먼트의 전체 길이를 알 수 있다.

 

[두번째 줄]

identifier, flags, fragment offset : 프래그멘테이션 어셈블리를 위한 필드이다.

IP 패킷이 a컴퓨터를 출발해서 b컴퓨터로 갈 때, 라우터를 거친다.

이때 라우터는 여러 다른 기종의 네트워크를 연결 시킬 수 있다.

그래서 라우터를 거치는 도중에 인터넷이 아닌, 인터넷보다 프레임 사이즈가 작은 네트워크를 지나갈 수도 있다.

(프레임 사이즈 = 해당 특정 네트워크가 통과시킬 수 있는 데이터의 최대 크기)

만약 이더넷보다 더 작은 크기의 데이터 전송 단위만 통과시킬 수 있는 네트워크를 지나가야 한다면 (PPP와 같은) 어쩔 수 없이 데이터를 그 사이즈에 맞게 잘라서 보내야한다.

(과거에는 이런 일이 꽤 많이 있었다고 한다.)

 

예를 들면 이더넷이 한번에 전송할 수 있는 단위인 1500바이트 크기로 전송하는데, 중간에 거치는 네트워크가 최대 500까지만 보낼 수 있다면 1500을 3조각으로 쪼개서 보내는 것이다.

그러면 목적지에서는 이 쪼개진 데이터들을 다시 하나로 모아서 하나의 패킷으로 만들어야 할 것이다.

그러면 목적지에 이게 어떤 순서로 도착할지 모르는데, 목적지에 잘 도착했을 때 원래 하나였다는 것을 구분할 방법이 필요하다. 그때 사용하는 것이 identifier로, 이 값이 같으면 원래 하나의 패킷이었다는 것을 알 수 있다.

 

만약 같은 id를 갖는 작은 패킷을 3개 받았다면, 그 순서를 알기 위해 fragment offset을 사용한다.

그래서 잘라지기 전에 위치가 첫번째였다면 offset이 0이 된다.

 

flag는 지금 받은 작은 패킷이 첫번째인지 아닌지, 그리고 이 이후에 추가적인 패킷이 있는지를 구분하는 플래그들이 존재한다.

 

그러나 지금은 거의 사용하지 않는다.

데이터링크 기술이 거의 이더넷으로 통일되었기 때문에 중간에 프래그멘테이션 되는 일이 거의 없다.

이더넷의 전송단위인 1500바이트로 보내면 프레그멘테이션 가능성이 무시할 수 있을만큼 낮다고 봐도 좋다.

 

[세번째 줄]

time to live (ttl) : 원래 이 필드가 나타내는 데이터의 단위는 '초' 였으나 지금은 hop count 의 의미로 사용된다.

그래서 하나의 라우터를 거칠 때마다 이 count 값이 1씩 감소한다.

 

만약 어떤 라우터가 받은 패킷이 자신이 목적지가 아니라면 hop count를 감소시키고 그 다음 라우터로 포워딩시킨다.

이 과정이 필요한 이유는, 어떤 패킷이 목적지를 찾지 못하고 라우터를 정처없이 떠도는 것을 방지하기 위함이다.

만약 어떤 네트워크로 가는 길목에 링크가 끊어졌거나해서 물리적으로 도착할 수 없을 때는 패킷을 버려야하는데, 패킷을 버리는 기준이 hop count 가 0이 되었을 때 이다. hop count가 0이된 패킷은 포워딩하지 않고 버린다.

이를 통해 링크 대역폭이 낭비되지 않도록 할 수 있다.

 

upper layer : 패킷이 갖고 있는 데이터가 어떤 종류의 데이터인지 나타낸다. 대표적인게 TCP, UDP 이다.

따라서 이 필드 값만 보고도 지금 갖고 있는 데이터가 TCP 데이터라는 것을 알 수 있다.

 

header checksum : 노이즈 감지 정도를 위해 존재하는데 공교롭게 노이즈가 나면 이 필드로도 체크할 수가 없어서 사실 의미없는 필드이다. IPv4가 오래전에 만들어진 프로토콜이라 어쩔 수 없이 쓰고 있고, IPv6에선 아예 빠져있다.

 

[6번째 줄]

Optoin : 유용한 옵션이 몇 개 있다.

예를 들면, IP 패킷이 거쳐가는 중간 경유지를 이 부분에 마킹해서, trace route 프로그램을 사용하지 않고도 이 위치에 내가 지나간 라우터 IP주소를 공간이 허용하는 최대한 마킹할 수 있었다. 물론 trace route 프로그램이 나온 이후에는 이 기법을 잘 사용하지 않는다.

또는 타임스탬프 같은 걸 마킹해서, 중간 경유지에 어떤 시각에 도착했는지 기록해서 각 경유지마다 가는데 걸리는 시간을 구간별로 측정할 수도 있다. 이것도 다른 방법이 있기 때문에 굳이 이렇게 측정하지 않는다.

IPv6에는 옵션도 빠져있다.

 

IP 주소

IP주소는 컴퓨터에 부여되는게 아니다.

사실 너 컴퓨터의 IP주소는 뭐냐고 묻는 질문은 틀린 질문이다.

정확한 질문은 '너 컴퓨터에 네트워크 인터페이스가 2개 있는데, 그 중에 wired 인터넷 네트워크 인터페이스에 부여된 IP주소가 뭐야?' 라고 질문하는 것이 정확하다.

물론 현실에서 이렇게 질문할 일은 없겠지만, IP주소는 네트워크 인터페이스에 부여된다. (호스트 컴퓨터든 라우터든)

 

인터페이스는 host나 라우터같이 우리가 보통 '컴퓨터'라고 부르는 장치와 그 장치가 네트워크와 연결되는 지점 (그 장치에 연결된 물리적 네트워크, physical link 의 연결 지점) 이다.

컴퓨터에서보면, PC의 네트워크 인터페이스 카드와 컴퓨터의 인터페이스 카드의 포인트가 연결되는 지점을 인터페이스라고 볼 수 있다.

 

라우터는 여러 네트워크를 연결하는 장치이기 때문에 당연히 여러개 인터페이스를 갖고 있다.

호스트는 인터페이스가 1개일 수도 2개일 수도 있다.

(보통 최근 나오는 노트북은 유선 인터넷 포트가 연결될 수도, wireless 802.11 (와이파이)에 연결될 수도 있다.)

 

IP주소는 그림과 같이 32bit 주소를 8개 bit씩 묶어서 10진수로 표현한 뒤 점으로 구분하는 dotted-decimal 표기법을 주로 사용한다.

 

 

실제로 각 인터페이스가 연결될 때는 2계층 기술을 활용하여 연결된다.

utp 케이블같은 유선을 이용하는 경우 이더넷 스위치를 사용하여 연결될 수 있고, 무선을 사용하는 경우 WiFi base station을 이용해서 연결될 수도 있다.

서브넷

서브넷의 정의는 중간에 라우터를 거치지 않고 서로 연결될 수 있는 인터페이스들의 모음을 말한다.

이전 그럼에서 라우터와 호스트 같은 장비들을 다 빼면 아래 그림과 같이 보인다.

위 그림에서 3개의 파란색 그룹 영역은 각각 작은 네트워크 서브넷을 이룬다.

 

IP주소는 크게 서브넷 파트와 호스트 파트로 구분된다.

같은 서브넷에 속하는 네트워크 인터페이스들은 공통의 상위 비트 주소값을 갖는다.

공통의 상위 비트를 제외한 나머지 하위비트를 호스트 파트로 부르며, 서브넷 내부의 각각의 인터페이스를 구분하기 위해 사용한다.

 

 

그래서 서브넷 파트의 IP주소를 위와 같이 IP주소와 / 슬래시 기호를 같이 이용해서 표시할 수 있다.

위 표시는 223.1.1 까지 24bit가 공통인 서브넷 네트워크를 나타낸다. (뒤의 0은 어떤 값이나 와도 된다는 뜻)

 

 

그렇다면 이 그림에서는 서브넷이 몇 개가 있을까?

얼핏보면 3개 같지만 사실 6개이다.

라우터와 라우터 사이 링크가 공유하는 IP주소를 보면 상위 주소가 공통적으로 겹치는 것을 볼 수 있다.

라우터라는 장비를 제거하고 네트워크 인터페이스에 매겨진 IP만 보면 서브넷을 이루는 것을 쉽게 이해할 수 있다.

 

그 내용을 그림에서 보면 위와 같다.

 

CIDR

CIDR (사이더)는 Classless InterDomain Routing 의 약자이다.

과거에는 서브넷 파트의 길이와 호스트 파트의 길이가 클래스로 구분되어 딱딱 정해져 있었다.

32bit 주소 중에서 1byte씩 단위로 묶어 늘려가면서 클래스를 분류하였다.

 

클래스 A 는 1바이트 길이의 서브넷을 갖고,

클래스 B는  2바이트 길이의 서브넷을 갖고,

클래스 C는 3바이트 길이의 서브넷을 가졌다.

 

즉, 과거에는 서브넷의 길이가 byte의 배수로만 허용을 하여 8, 16, 24가 전부였다.

하지만 이렇게 하니 24bit 를 서브넷으로 하는 경우, 남은 host 파트의 크기가 8bit 로 이론적으론 256개의 네트워크 인터페이스 장치를 구분할 수 있었다.

그런데 내가 서브넷 내에서 만약 IP주소를 할당하고 싶은 컴퓨터의 개수가 100대이고, 각각의 컴퓨터에는 1개의 네트워크 인터페이스가 있다면 사실 100개의 IP주소만 알면 된다.

그런데 이 클래스 분류의 제한 때문에 256개의 IP주소를 받게되어 나머지 150여개의 주소를 낭비하는 셈이된다.

 

따라서 CIDR는 서브넷을 조금 더 융통적으로 쓸 수 있도록 이 제한을 해제하였다.

즉, 클래스를 무시하고 서브넷 길이를 byte의 배수가 아니라 자유로운 숫자로 쓸 수 있게 한 것이다. (여전히 바이트 단위로 서브넷 길이를 사용하는 경우가 많기는 하다.)

 

그러면 위 예시에서는 25bit의 서브넷 길이를 두어서 나머지 하위 7비트로 128개의 IP주소를 받아 호스트를 구분하면 된다.

아까보다 훨씬 더 효율적으로 IP주소를 분배할 수 있게 되었다.

 

특히 IP주소를 부여해주는 ISP 입장에서는 100개의 IP주소를 필요로 하는 두 회사에 대해 이전에는 클래스 C 서브넷을 2개 떼어줘야 했다면, CIDR의 등장 이후로는 25bit 길이의 서브넷을 2개 주면 되니 더 효율적이다.

 

이렇게 하는 이유는 IP주소가 절대적으로 부족하기 때문이다.

IP주소는 32bit 주소로서 최대 42억개의 주소를 나타낼 수 있다.

그런데 전 세계 인구는 80억에, 한명이 여러개의 네트워크 디바이스를 사용한다. (IoT 등)

따라서 과거에는 충분했을지 몰라도 이제는 IP주소가 부족해졌다.

 

게다가 미국은 인터넷이 시작된 국가라서 자신들이 사용할 수 있는 IP 주소 범위가 넓은데, 우리나라 같은 후발주자들은 남은 IP주소가 적어서 아껴써야 하는 상황이다.

 

이런 IP주소 부족 문제는 IPv6를 쓰면 사실 해결되기는 하지만, 이 버전으로 업그레이드는 일어나지 않고 있다.

IPv4로도 문제를 해결할 수 있는 여러 기술들이 존재하기 때문이다.

이 내용도 뒤에서 정리한다.

 

 

CIDR는 이렇게 subnet part의 길이를 23bit와 같이 유동적으로 정할 수 있게 해준다.

이를 노테이션을 쓸 때는 dotted decimal 표현 뒤에 / 를 붙이고 subnet part의 bit 길이를 써준다.

 

IP주소의 획득

그렇다면 이 IP주소는 어떻게 얻을 수 있을까?

IP주소를 얻는다는 말은 사실 2가지를 얻는 것과 같다.

첫번째는 서브넷 주소를 얻는 것이고, 두번째는 host 주소를 얻는 것이다.

 

보통 일반적으로 노트북과 같은 장치의 네트워크 인터페이스에 IP주소를 부여할 때는 DHCP (Dynamic Host Configuration Protocol) 라는 프로토콜을 이용해서 인터넷을 사용하는 순간에만 동적으로 IP주소를 부여한다. (plug and play)

학교나 회사 같이 고정된 상황이면 바뀌지 않는 정적 IP주소를 사용한다.

UNIX 서버라면 /etc/rc.config 와 같은 파일에 IP주소가 하드코딩 되어있고, 윈도우는 ipconfig 명령어를 통해 알 수 있다.

 

DHCP

DHCP의 목적은 호스트가 네트워크 내에 접속했을 때, 네트워크 서버로부터 동적으로 IP주소를 할당받는 것이다.

왜냐하면 항상 이 네트워크에 들어와있을 것이라는 보장이 없기 때문에 항상 똑같은 IP주소를 매번 사용할 이유가 없다.

(서버가 아닌 이상 네트워크에 들어왔다가 나갔다가를 반복할 것이기 때문이다.)

 

그래서 기본적으로 IP주소를 대여받아서 쓰다가, 대여 기간이 지나면 필요한 경우 대여를 연장해서 사용한다.

네트워크 서버는 빌려줄 수 있는 IP주소 중에 하나를 빌려주고, 똑같은 IP주소를 계속 재사용하는 것을 허용하기도 한다.

DHCP는 특히 모바일 장치에게 유용한 프로토콜이다.

모바일 장치는 이동하면서 계속 access network가 변할 수 있기 때문이다.

 

DHCP는 크게 4가지 동작을 수행할 수 있다.

 

1. host 컴퓨터는 DHCP 서버의 정보를 얻기 위해 DHCP Discover msg를 broadcast 할 수 있다. (optional)

물론 이후에 서버 정보를 얻어오면, 이후에는 이 과정을 생략한다.

 

2. DHCP서버는 이 브로드캐스트 요청을 받으면 DHCP offer msg를 응답한다. (optional)

이 과정도 필수는 아니다. 이름에서 볼 수 있듯이 서버는 브로드캐스트 요청에 대해 '제안'을 응답한다.

호스트는 이를 수락할 수도, 거부할 수도 있다.

 

3. 서버가 제안한 IP주소를 호스트가 수락하면 (보통은 수락한다) '너가 제안한 IP주소를 사용하겠다!' 라는 뜻으로 사용을 요청하는 DHCP request 메세지를 보낸다. 

 

4. 서버가 이 요청을 수락하면 DHCP ack를 응답한다.

 

DHCP는 이렇게 client-server 패러다임을 따른다.

참고로 DHCP 서버는 라우터 내부에 구현이 되어있는 경우가 많다. (꼭 그래야 하는 건 아니다.)

그래서 자신에 연결된 서브넷에 대한 DHCP 요청을 라우터가 처리한다.

 

예시로, 위와 같은 그림의 네트워크가 존재한다고 해보자.

이 네트워크에 새로운 호스트가 접근하기를 원하는 상황이 발생했다.

 

이 네트워크에 처음 접근하는 클라이언트는 우선 DHCP 서버를 찾기 위해서 broadcast로 DHCP discover 요청을 보낸다.

 

이때는 아직 IP주소를 부여받기 이전이므로 src IP주소는 0으로 설정되어 있다.

당연히 이 주소는 유효한 주소가 아니며, 내가 아직 IP주소가 없다는 것을 의미한다.

 

그리고 요청을 보낼 때 목적지 주소는 255.255.255.255 로 보낸다.

목적지 주소 역시 모르기 때문에 255.255.255.255 라는 브로드캐스트 전용 목적지 주소로 요청을 보내는 것이다.

DHCP가 아닌 호스트는 이 요청을 무시할 것이고, DHCP 서버는 이를 받아서 어떤 응답을 보내줄 것이다.

 

위 그림에서 IP주소 옆에 있는 67, 68 은 port 번호라고 보면 된다.

yiaddr 는 나의 IP주소를 의미한다. 없으므로 0으로 설정해둔다.

 

transaction ID는 내가 응답을 받았을 때, 요청과 응답을 매칭시키기 위한 ID이다.

 

 

만약 DHCP 서버가 새로 온 클라이언트의 요청을 받았다면, 다시 브로드캐스트 방식으로 자신의 IP주소를 알린다.

이떄도 브로드캐스트 방시을 사용하는 이유는 클라이언트가 아직 자신의 IP주소가 없어서 src 주소로 0.0.0.0 을 지정했기 때문에 서버도 클라이언트를 특정할 수 없기 때문이다.

 

 

동시에 클라이언트가 사용할 수 있는 IP주소를 yiaddrr 에 담아서 같이 제안한다.

이때 lifetime을 지정하는 경우도 있는데, 보통은 이 시간을 넉넉하게 설정한다.

위 예시에서는 3600초로 지정했다.

만약 이 시간이 다 지나더라도 요청에 따라 연장할 수도 있다.

 

위 두 과정은 클라이언트가 처음 네트워크에 접근했을 때 발생하는 과정이고,

만약 전에 온 적 있는 네트워크라면 위 두 과정은 생략될 수 있다.

따라서 클라이언트가 전에 사용했던 DHCP 서버의 주소를 기억하고 있으면 굳이 discover 메세지를 보낼 필요가 없다.

 

그런데 DHCP 서버를 찾기 위해서 굳이 모든 서버에 요청을 보내서 다 깨워야 할까?

그래서 DHCP 프로토콜 명세에는 위 두 과정을 유니캐스트로 구현할 수 있다고 명시해두었다.

다만 브로드캐스트를 쓰는 이유는 내가 이 IP 주소를 얘한테 할당했으니 나머지는 쓰면 안된다고 알려주는 효과를 낼 수도 있기 때문에 쓰는 것도 있다. 그런데 굳이 그런 효과가 필요없다고 느껴진다면 유니캐스트로 보낼 수도 있다.

 

클라이언트는 자신이 알고있는 DHCP 서버로 DHCP 서버가 제안한, 또는 전에 제안받아서 썼던 IP주소를 이어서 사용하고 싶다는 요청을 보낸다.

 

 

그러면 DHCP 서버는 사용해도 좋다는 ack를 보내는 것으로 IP가 부여된다.

 

이때 ACK에 yiaddrr 에 사용하면 되는 IP주소가 담기게 된다.

 

DHCP 서버가 돌려주는 정보는 클라이언트 네트워크 인터페이스에 부여된 IP주소를 돌려주는 것이 제일 중요한 역할이지만, 그것 이외에도 클라이언트가 인터넷에 연결되기 위해 추가적으로 꼭 필요한 정보들도 준다.

 

첫번째는 first router 이다. 클라이언트로부터 외부로 나가는 트래픽이 맨 처음으로 가야할 라우터의 위치를 알아야한다.

두번째는 DNS 서버의 정보가 필요하다. 도메인을 IP로 바꾸는데 필요한, 현재 네트워크에서 접근 가능한 DNS 서버의 정보를 알아야 한다.

세번째는 네트워크 마스크이다. 내가 할당받은 IP주소의 서브넷 파트가 얼마고, host 파트가 어느 정도인지를 알아야 한다.

그래서 이때 전달하는 정보가 Subnet Mask 이다. 말 그대로 호스트 파트를 가리는 마스크를 씌워서 그 남은 부분으로 서브넷을 파악하는 것이다.

 

Example

 

새로운 네트워크에 접근하는 컴퓨터는 DHCP 서버에 IP주소를 요청한다.

IP주소 뿐만 아니라, first router 정보,  DNS 서버 정보도 같이 요청한다.

 

DHCP는 일종의 어플리케이션이기 때문에 UDP로 캡슐화되어 DHCP 서버에 요청을 보낸다.

이때 이더넷 프레임은 브로드캐스트되어 DHCP에 전달된다. (데이터링크 계층의 브로드캐스트, 이때도 목적지가 모두 1이다.)

 

전송된 데이터는 서버에서는 거꾸로 올라가면서 디먹스된다.

 

 

DHCP서버는 ACK를 만들어서 IP주소, first router, DNS 서버 정보를 포함시켜 응답을 보낸다.

host는 이 정보를 받아서 자신의 IP주소를 알게 된다.

---

Subnet 의 할당

그러면 DHCP에서 서브넷 정보를 알려줄 때, 어떤 기준으로 서브넷 정보를 알려줄까?

서브넷 파트의 할당은 ISP의 정책에 따라 정해진다.

 

예를 들어 홍대는 ISP 2군데의 서비스를 받고 있다.

이때 각각의 ISP는 자사가 보유하고 있는 IP주소 블록이 있다.

ISP는 자신이 보유한 주소블록 중 일부를 떼어내서 고객사 (홍대) 에게 주소를 할당해준다.

 

예를 들어 IP 주소 100개를 필요로 한다면, ISP가 서브넷 파트를 25bit로 만든 다음, 이 서브넷을 고객사에 할당해주는 것이다. 그러면 고객사는 그 서브넷 밑에서 128개의 IP주소를 사용할 수 있게 된다.

 

만약 서강대도 같은 크기를 요청했다면 홍대에는 25번째 bit가 0인 서브넷을, 서강대에는 25번째 bit가 1인 서브넷을 할당해줄 수 있다.

그러면 ISP는 클래스 C 서브넷 블록 하나를 가지고 고객사 두 군데를 지원할 수 있다.

 

따라서 서브넷을 얼만큼 할당할 것인지는 ISP가 고객사의 요구사항을 보고 결정한다.

 

간단한 예시를 보자.

ISP가 갖고 있는 블록이 위와 같이 서브넷 20bit 짜리 블록이라고 해보자.

ISP는 이 블록을 통해 나머지 12bit 로 IP주소를 구분할 수 있으니 총 4096개의 IP주소를 갖고 있다.

만약 이 블록을 8개로 균등하게 쪼개서 나눠준다고 하면, 서브넷 파트를 3비트 추가적으로 늘려서 나눠주면 된다.

8개 회사는 000 부터 111 까지 3개 비트로 구분할 수 있기 때문이다.

각 회사는 남은 9비트로 구성할 수 있는 IP를 갖게 될 것이다. (총 512개)

 

만약 하나의 회사 내에서 부서에 따라 또 서브넷을 구분하고자 한다면, 서브넷 영역을 또 다르게 나눠서 부서마다 다르게 IP를 할당할 수도 있다.

 

Route Aggregation

라우터 어그리게이션은 라우터 경로를 라우터끼리 교환하는, 경로 교환에 대한 내용이다.

 

 

위 그림과 같이 인터넷에 연결된 ISP 회사 2개가 있다고 해보자.

첫번째 ISP 는 200.23.16 이라는 20bit 서브넷을, 두번째 ISP는 199.31 이라는 16bit 서브넷을 갖고 있다.

첫번째 ISP 의 고객사는 그림과 같이 8개의 고객사로 나누어져, 23bit의 서브넷을 할당받은 상태이다.

 

첫번째 ISP 는 인터넷에 광고할 때 2.23.16.0/20 에 해당하는 IP는 자기한테 보내라고 광고한다.

그래서 인터넷 외부에서 7번 회사로 가는 트래픽이 존재하면, 이 트래픽은 첫번째 ISP를 거쳐서 7번 회사로 갈 수 있다는 것을 알 수 있다.

 

그리고 이런 정보를 라우터끼리 교환한다.

그런데 첫번째 ISP 가 광고하는 내용은 각 회사에 대해 따로따로 광고하는게 아니라, 각 회사가 공통적으로 사용하는 서브넷을 뭉뚱그려서 광고한다. (즉, 23bit 서브넷이 아니라 자기가 가진 20bit 서브넷으로 광고한다.)

 

이렇게 경로를 합쳐서 광고하는 것을 route aggregation 이라고 한다.

그러면 광고하는 데이터의 크기가 줄어드는 이점이 생긴다.

 

두번째 ISP 는 16bit 서브넷을 주소블록으로 갖고 있고, 이렇게 뭉뚱그려서 광고하고 있던 상황이다.

그런데 첫번째 ISP의 회사 1이 ISP를 바꾸기로 결정했다고 해보자.

일종의 번호이동과 같다.

 

이때 두가지 옵션이 있다.

첫번째는 회사1에 부여된 IP주소를 회수하고, 두번째 ISP에 가서 아예 새로운 서브넷을 할당받아 IP를 전부 바꾸도록 하는 것이다. 이건 간단한 일이 아니지만 보통은 ISP가 이것까지 직접 다 해주겠다고 한다.

 

두번째는 그림과 같이 첫번째 ISP가 부여해주었던 그 서브넷을 갖고 그대로 옮기는 것이다.

이러면 첫번째 ISP 입장에서는 자신들의 주소 블록이 상대 회사로 넘어간 것과 같기 때문에 손해이다.

하지만 실제로는 이런 일이 자주 일어나는데, 첫번째 ISP와 두번째 ISP가 서로 계약을 맺어서 우리 고객들이 서로 이동할 때는 IP를 그대로 갖고 갈 수 있도록 하자는 약속을 한 것이다.

만약 한쪽으로 쏠림이 생긴다면 그때는 돈을 지불하도록 할 수도 있다.

 

그러면 두번째 ISP는 어떻게 회사 1의 IP주소를 알 수 있을까?

첫번째 ISP는 기존에 하던 광고를 여전히 할 수 있는 걸까?

자신이 광고하는 서브넷에 속하는 회사 1이 이제는 자신한테 없는데 그렇게 광고를 하면 안되는 것 아닐까?

 

사실 이거는 두번째 ISP에서 광고를 할 때 한가지 옵션을 추가하면 간단하게 해결된다.

 

바로 새로 추가된 그 ISP의 23bit 서브넷을 그대로 광고하는 것이다.

이렇게 했을 때 문제가 해결되는 이유는 IP주소로 목적지를 찾을 때 Logest Prefix Matching 을 사용하고 있기 때문이다.

 

---

추가적인 내용

그렇다면 ISP는 자신의 블록들을 어떻게 할당받을 수 있을까?

이건 ICANN (Internet Corporation for Assigned Name and Numbers) 라는 기관에서 부여한다.

풀네임에서 알 수 있듯이 이름과 숫자에 관련된 것을 총괄하는 기관이다.

이름에 해당하는 것은 도메인 이름같은 것을 말한다.

그래서 루트 네임서버의 카피 서버를 우리나라에 새로 만들고 싶다면 이 기관의 허락을 받아야 한다.

DNS root, TLD를 관리한다.

 

숫자는 IP주소를 말하며, IP주소의 할당을 관리한다.

하지만 안타깝게도 미국이 IPv4의 주소를 많이 할당 받았고, 나머지 국가들이 나머지를 나눠쓰려고 하다보니 후발주자의 IP주소가 부족한 상황이다. 그리고 미국의 입김이 세다고 한다..

 

2011년에 마지막 IP주소 블록이 할당되어서 남은 IP주소가 없다고하나, NAT와 같은 장비를 이용해서 하나의 IP를 여러 디바이스가 나눠 쓸 수 있도록 하는 방법으로 IP주소 부족 문제에 대처하기도 한다.

 

또 이 문제를 해결하기 위해 128bit 주소를 갖는 IPv6가 만들어졌다.

하지만 이 주소 체계는 아직 널리 쓰이지는 않는다.