CH4 : Network Layer (3)

* 이 글에 관련된 모든 내용은 Computer Networking A Top-Down Approach 7th에서 가져온 내용이다. *

 

DHCP(Dynamic Host Configuration Protocol)

---

DHCP는 host가 켜졌을 때 자동으로 네트워크를 찾게 해주는 프로토콜이다.

(예를 들어 우리가 컴퓨터를 키면 컴퓨터가 자동으로 네트워크를 찾아주듯이)

DHCP서버는 전원이 켜진 host에게 자신의 서브넷 네에서 사용할 수 있는 IP를 할당해주는데, 한번 IP를 주고나서 host가 네트워크를 사용하지 않는데도 IP를 할당받은 채로 있으면 IP주소의 낭비가 발생한다.

따라서 lifetime도 함께 넘겨줘서 해당 시간내에 다시 요청이 오지 않으면 클라이언트는 할당받은 IP를 반납하는 식으로 구성된다.

 

 

현재 클라이언트는 DCHP서버로부터 IP를 받아오고 싶은데 클라이언트는 네트워크에 연결하지 않았으므로 DHCP 서버의 IP도 모르고 심지어 자신의 IP도 모르는 무지성 상태이다.

 

그렇다면 어떻게 DHCP로부터 IP를 받아올까?

 

DHCP는 기본적으로 4가지 단계로 이루어져있다.

또한 이 주고받는 과정은 connection이 되기 전 과정이므로 connection setup을 할 수 없어 UDP를 통해 통신한다.

1. DHCP Discover

현재 클라이언트는 DHCP의 IP주소를 모르기 때문에 브로드캐스트(subnet의 모두에게 뿌림)를 한다. (255.255.255.255) 이때 자신의 IP조차 모르는 클라이언트는 자신이 누군지 서버에게 알리기 위해 임의의 포트넘버를 붙여 전송한다.

 

2. DHCP Offer

어떤 모르는 클라이언트로 부터 포트넘버만을 받은 DHCP서버는 이게 누구에게서 왔는지 모르기 때문에 (클라이언트는 자신의 IP가아닌 포트넘버만 보냈기 때문) 역시 브로드캐스트를 통해 자신의 포트넘버와 IP를 보낸다. 이때 lifetime도 같이 넘겨준다. 

3. DHCP Request

자신이 보낸 포트넘버가 포함된 메시지를 어떤 모르는 이로부터 전달받은 클라이언트는 이 메시지가 DHCP서버로부터 온것임을 짐작할 수 있다. 때문에 서버에게 자신에게 IP를 할당해달라고 요청을 한다.

그러나 이때 클라이언트는 서버로부터 서버의 IP를 받아서 서버의 IP주소를 알고있지만 그냥 브로드캐스트를 통해 요청한다. (왜인지는 모르겠다..)

4. DHCP ACK

IP를 달라는 메시지를 받은 서버는 역시 아직도 클라이언트의 IP를 모르기때문에 자신에게 온 포트넘버를 포함시켜 할당할 IP를 보낸다. 그리고 마침내 클라이언트는 자신의 IP를 얻게된다.

 

이때, 메시지를 보면 transaction ID가 포함되었음을 볼 수 있는데, 이는 여러 클라이언트가 동시에 DHCP 서버에게 요청을 보낼때 클라이언트를 구분하기 위함이다.

 

전체적인 과정은 위 그림으로 이해할 수 있다.

그러나 만약 중간에 로스가 나서 제대로 된 ACK을 받지 못했다면 다음 그림과 같이 재전송한다.

 

NAT(Network Address Translation)

---

네트워크 주소를 바꿔주는 기술이다. 

IPv4는 32bit의 IP주소를 표현하기 때문에 이미 2011년에 사용할 수 있는 IP주소가 고갈이 되었는데 이 NAT덕분에 아직도 IPv4를 사용할 수 있다.

 

NAT는 기본적으로 다음과 같은 아이디어를 사용한다.

어떤 pbulic한 IP를 가진 라우터를 기점으로 private network를 만든다. 여기서 pulblic한 IP라는 것은 globally unique하다는 것이다. 만들어진 private network안의 호스트들은 private network안에서만 통신하기 때문에 그 안에서만 IP가 겹치지 않으면 다른 network에 있는 IP들과 IP가 같아도 상관이 없다. 

 

즉 어떤 pbulic 한 IP를 가진 라우터를 기점으로 private network를 생성해 세계 전체에서 고유한 IP는 private network를 총괄하는 하나의 라우터만 가지고 있으면 된다.

 

이 방식에는 여러가지 장점이 있다.

1. ISP로부터 어떤 범위의 IP주소들을 받아올 필요가 없다. 하나의 public한 ID만 받아오면 그 라우터를 기점으로 private한 네트워크를 만든다.

2. private network안에 있는 호스트들은 다른 network에 상관없이 자신의 주소를 마음대로 바꿀 수 있다.

3. private network안에 있는 호스트들은 기점 router밖에있는 network에선 절대 접근할 수 없다. (당연하다) 때문에 보안성에서 장점이 있지만, 이 점은 어떤 부분에선 단점이 될 수도 있다.

 

그럼 이 방식은 어떤 과정을 거칠까?

기본적으로 라우터는 라우팅 테이블을 가지고 있다.

private network안에 있는 호스트는 바깥세상으로 나가고 싶을때 router를 거쳐 router의 IP로 변환이 되고, 라우터는 그때마다 새로운 포트넘버를 할당해 자신의 private network안에 있는 호스트랑 매치한다. (라우팅 테이블)

그리고 통실할때 라우팅테이블에 존재하는 매치로 데이터가 수신/송신된다.

잘 따라가보며 이해해보자.

 

장점만 있는 것만이 아니라 문제점도 있다.

1. 포트넘버를 통해 private network안에 있는 호스트들을 매치하기 때문에 사용가능한 포트넘버의 개수만큼만 호스트를 포함할 수 있다. 근데 포트넘버는 16비트로 충분히 크다. well-knonw포트를 제외해도 정말 많으므로 별 상관은 없다.

2. 라우터는 기본적으로 layer3(network layer)까지 처리를 하는데, 포트넘버를 관리하기 때문에 layer4도 고려해야 한다.

3. 원래 src IP와 dst IP는 절대 건드리면 안된다는게 전통적인 네트워크에서의 법이지만 NAT는 이를 무시한채 바꾸고 있다. 때문에 어떤 오류가 생길지는 아무도알 수 없다.

4. 전통적인 P2P방식이 불가능하다. private network안에 server역할을 하는 노드가 있다면 다른 네트워크에 있는 클라이언트들은 이 노드의 IP를 알 수 없다.(라우터를 통해 변환된 IP는 알 수 있을듯..?)

 

위와 같은 문제를 해결하기 위한 몇가지 방법이 있다.

앞에서 말한것과 같이 라우팅테이블을 통해 라우터를 거쳐 통신하게 하는 것이다. 

 

또한 스카이프에서 쓰는 방식도 있는데 어떤 스카이프라는 하나의 relay서버를 두어 매칭시키는 방법이다.

 

ICMP

---

이전글에서 언급했듯이 IP는 별다른 기능이 없다. 왜 그런지는 설명했었다.

때문에 패킷 error에 대한 리포팅 기능이 없는데 이를 보완해주기 위해 ICMP라는 프로토콜이 존재한다.

 

ICMP는 기본적으로 error reproting과 네트워크 진단 기능의 역할을 한다.

데이터그램이 에러를 일으키면 ICMP는 에러 조건을 source에게 보낸다. (왜 에러가 발생했는지에 대해)

 

이때 ICMP는 첫 frament에 대해서만 에러를 리포팅하고 헤더 체크섬에 에러가 발생하면 메시지를 보내지 않는다.

ICMP은 Layer 3가 기능함에 있어서 도움을 주기 때문에 마치 Layer 4처럼 작동하지만 실제로는 L3에 속해있다.

 

여러 에러 type들에 대한 ICMP의 코드들이다. 

에러들에는 다음과 같은 종류가 있다.

 

1. Echo Request/Reply

2. Destination Unreachable

3. Time Expired