RARP, BOOTP, DHCP

RARP: Reverse ARP(Address Resolution Protocol)

BOOTP: Bootstrap Protocol 

DHCP: Dynamic Host Configuration Protocol

 

 

 

RARP

하드디스크가 없다면 또는 저장공간이 부족하다면  IP주소와 관련 자료구조들을 저장할 공간이 없다.

IP 주소를 얻어와야, OS를 포함한 데이터를 다시 받아올 수 있다.

그러한 일련의 과정을 위해 RARP(Reverse ARP) 가 등장했습니다.

상대 IP 주소를 이용해 상대 Mac 주소를 얻어내는 ARP 와는 달리

RARP 는 자신의 Mac 주소에 대응하는 자신의 IP 주소를 얻어오는 프로토콜 입니다.

컴퓨터에는 programmable ROM이라는 조그만한 메모리가 존재한다.

이 ROM 안에 Mac 주소와 조그만한 프로그램 정보들이 들어있어서 이를 통해 IP 주소를 얻어오는 것이 RARP의 주 목적입니다.

RARP server는 Mac 주소에 대응하는 IP 주소와 여러 정보들을 담고있죠. 현재 DHCP 패킷의 형태도 RARP 의 모습과 굉장히 유사합니다..

 

RARP의 단점

• IP 주소밖에 가져올 수 없습니다.
• link layer broadcast 방식이므로, 모든 링크마다 서버가 존재해야 합니다.
• OS 에 존재하지 않고 적용 계층에 존재하기에, 계층 원리를 어깁니다.

이 단점을 보완하기 위해 BOOTP가 등장한다.

 

 

RARP 통신 과정

 

1. PC는 자신의 MAC 주소만 알고 있는 상태로 IP 정보를 알아와야 한다. 이때 RARP Request 요청을 같은 네트워크 대역에 Broadcast 한다.

2. Server는 RARP Request를 받아 PC의 IP주소를 담아 RARP Reply를 PC의 주소로 Unicast 한다.

 

두 프로토콜 모두 최초에 MAC 주소 또는 IP주소 둘 중 하나를 모르고 있는 상태이기 때문에 Request 값을 보낼 때는 Broadcast한다. 하지만 Reply 값을 보내는 쪽에서는 이미 상대방이 자신의 정보를 보내왔기 때문에 Unicast로 Reply값을 보내는 것이다.

 

정리하자면

ARP는 IP주소 -> MAC 주소로 변환

RARP는 MAC주소 -> IP주소로 변환

최초에 정보를 요청(Request) 할 때는 Broadcast , 응답(Reply)을 보내는 쪽은 Unicast 한다.

 

---

BOOTP

RARP의 단점을 보완하기 위해 BOOTP 가 등장한다.

RARP를 구현하기 위하여 접근해야 하는 계층은 물리 계층이다. => 좀 더 상위계층에서 구현할 수 있는 기법이 있다면 개발이 좀 더 쉬울 것이다. => 이렇게 해서 나온 것이 BOOTP

BOOTP의 장점

• IP 뿐만 아니라 다른 data도 가져올 수 있다.
• BOOTP Relay를 통해 remote configuration을 할 수 있어서 링크마다 서버가 있을 필요가 없다.
• UDP를 이용하기 때문에 계층 원리를 어기지도 않습니다.

DHCP는 BOOTP와 매우매우 유사하며, 현재 DHCP 서버는 아직도 BOOTP 와의 통신을 지원합니다.

 

BOOTP 클라이언트 및 서버

다른 많은 TCP / IP 프로토콜과 마찬가지로 BOOTP는 실제로 클라이언트 / 서버이다.

프로토콜의 작동은 BOOTP 클라이언트와 BOOTP 서버 간의 단일 메시지 교환으로 구성된다.

 

BOOTP 클라이언트는 구성해야하는 모든 유형의 장치가 될 수 있다.

BOOTP 서버는 BOOTP 클라이언트 요청에 응답하도록 특별히 설정된 네트워크 장치이며, 주소 지정 및 필요한 경우 클라이언트에 제공 할 수 있는 기타 정보로 프로그램이 구현된다.

 

BOOTP 서버는 서비스를 제공하는 클라이언트에 대한 특별한 정보 집합을 유지 관리한다.

여기에서 하나의 핵심 부분은 테이블이다.

이 테이블은 각 클라이언트의 하드웨어 (Layer 2, 데이터 링크 계층) 주소, 즉 MAC주소를 해당 장치에 할당 하고자 하는 IP 주소로 매핑하는 테이블이다.

 

클라이언트는 요청에서 하드웨어 주소를 지정하고, 서버는 이 주소를 사용하여 클라이언트의 IP 주소를 찾아서 클라이언트로 응답한다.

물론, 구현하기에 따라 다르고, 다른 기술도 사용할 수도 있겠지만, 매핑 테이블이 가장 일반적인 구현방법이다.

 

 

메시지 및 전송

그런데, BOOTP 메시징은 몇 가지 이유로인해, 계층 4 전송 프로토콜로 TCP가 아닌 UDP (User Datagram Protocol)를 사용한다. 

 

첫째, UDP는 다른 레이어 4 전송 프로토콜인 TCP보다 훨씬 덜 복잡하며, BOOTP와 같은 간단한 "요청 / 응답"프로토콜에 이상적이다.

 

둘째, 클라이언트가 분명히 BOOTP 서버의 주소를 알지 못하기 때문에 요청은 로컬 네트워크에서 브로드 캐스팅되야 한다.

UDP는 브로드 캐스트를 지원하지만 TCP는 브로드 캐스트를 지원하지 않는다.

 

UDP는 BOOTP 서버에 대해 잘 알려진 (예약 된) 포트 번호 인 UDP 포트 67을 사용한다.

BOOTP 서버는 클라이언트가 보낸 이러한 브로드 캐스트 BOOTP 요청에 대해 포트 67에서 "수신 대기"한다.

요청을 처리 한 후 서버는 클라이언트에게 응답을 보낸다.

이 처리 방법은 클라이언트가 자체 주소를 알고 있는지 여부에 따라 다르다.

 

 

◎ 클라이언트가 주소를 알고 있는 경우

BOOTP 클라이언트가 이미 자신의 주소를 알고있는 경우가 있다. 이 경우는, BOOTP 서버가 이 주소를 직접 응답을 다시 보낼 때 사용할 수 있다.

 

 

◎ 클라이언트는 자신의 주소를 모르는 경우

물론 BOOTP는 주소를 모르는 클라이언트에게 IP 주소를 제공하기 위해 흔히 사용 된다. 

이것은 종종 "닭고기와 계란"문제라고 불리는데, 그 이유는 "닭고기와 계란"이라는 오래된 수수께끼와 같은 종류의 "고리"를 나타내기 때문이다.

이 딜레마를 해결하기 위해 BOOTP 서버에는 두 가지 선택지가 있다.

운영체제가 이를 지원하면 서버는 클라이언트의 하드웨어 주소를 사용하여 장치에 대한 ARP 항목을 만든 다음 레이어 2 유니 캐스트를 사용하여 응답을 전달할 수 있다.

그렇지 않으면 회신을 로컬 네트워크에서 브로드 캐스트로 전송해야한다.

 

 

브로드 캐스트 및 포트 사용

BOOTP 서버가 클라이언트로 다시 브로드캐스트 해야한다는 사실은 대부분의 TCP/IP 프로토콜이 클라이언트 포트를 사용하는 방식에서 약간의 변화가 필요하다.

일반적으로 클라이언트/서버 트랜잭션에 UDP 또는 TCP를 사용하는 클라이언트는 임시 또는 잠시사용하기 위한 포트 번호를 생성하여 요청메세지의 소스포트로 사용한다.

 

서버는 그 임시 포트 번호를 사용하여 클라이언트의 IP 주소로 응답을 보낸다.

임시 포트 번호는 특정 IP 주소에 대해 고유해야하지만, 네트워크의 모든 장치에서 고유하지는 않는다.

 

이해하기 쉽게 한가지 예를 들어 보면, 이런것이다.

하나의 네트워크상에 두 장치 A, B가 있다.

장치 A는 웹 서버에 대한 HTTP 요청에 임시 포트 번호 1248을 사용하고, 장치 B는 TCP/IP 스택에서 포트 번호 1248을 사용하여 DNS 요청을 보낼 수 있다.

서로다른 장치가, 동일한 네트워크상에 있다 하더라도, 동일한 포트 1248을 사용할 수 있다는 것이다.

 

BOOTP의 서버가 브로드캐스트이기 때문에 유니캐스트 전송을 사용하는 특정 장치를 대상으로하지 않는다.

즉, 일시적인 포트 번호로 안전하게 보낼 수 없다는 것을 의미한다.

 

네트워크상의 다른 장치는 다른 트랜잭션에 대해 동일한 임시 포트 번호를 선택했을 수 있으며 BOOTP 서버의 응답을 실수로 자기에게 보낸것으로 오인 할 수 있다.

이 문제를 피하기 위해 잘 알려진 다른 포트 번호가 BOOTP 클라이언트에만 사용된다.

UDP 포트 68 이 바로 그것이다.

 

클라이언트는 브로드캐스트 또는 유니캐스트 전송을 위해서 이 포트에서 수신 대기하지만, BOOTP 요청을 보낸적이 없는 클라이언트는 무시할 것이다. 

이 "이중 브로드 캐스트"BOOTP 통신 프로세스는 아래 그림에 나와 있으니 참고하자.

이 그림을 간단히 설명하겠다.

장치 A는 IP 주소 및 기타 매개 변수를 확인하려고 시도하고 있다.

UDP 포트 67을 사용하여 로컬 네트워크에서 BOOTP 요청을 브로드캐스트 한 다음 포트 68에서 응답을 수신한다.

장치 D는 BOOTP 서버로 구성되어있고, 67 포트에서 수신 대기한다.

요청을 받으면 포트 68에서 A에게 IP 주소가 무엇인지 알려주는 브로드캐스트를 보낸다.

BOOTP는 브로드 캐스트를 사용하여 할당 된 IP 주소가없는 장치와의 통신을 허용하는 비교적 간단한 클라이언트/서버 프로토콜임을 생각하면 매우 간단한 과정이다.

 

 

세줄 요약 주요 개념

1. BOOTP 클라이언트는 브로드 캐스트를 사용하여 청취 BOOTP 서버에 요청을 보낸다.
2. 대부분의 경우 BOOTP 클라이언트 장치는 프로토콜을 사용할 때 자체 IP 주소를 알지 못한다. 
3. 이런 이유 때문에 BOOTP 서버는 일반적으로 응답을 전송할 때 브로드 캐스트를 사용하여 클라이언트에 도달하는지 확인한다.

 

손실 된 메시지의 재전송

BOOTP 메시지 전송을 단순하게 하기위해 UDP를 사용할때의 단점은 전송 품질을 보장할 수 없다는 것이다.

UDP특성을 이미 알고 있겠지만, UDP는 신뢰할 수 없다.

즉, BOOTP 클라이언트로부터 전송된 요청메세지가 서버에 도착하기 전에 손실될수도 있고, 운좋게 서버에 도착했더라도, 클라이언트 방향으로 전송된 서버의 응답 메세지가  도착하지 않을 수 있다. 

 

 

이쯤 읽으면 '응? 장난하냐??' 하는 생각이 들겠지만, 진정하고 계속 읽어보자.

BOOTP는 이에대한 대비책을 가지고 있다.

 

 

UDP를 사용하는 다른 프로토콜과 마찬가지로 BOOTP 클라이언트도 재전송 타이머를 사용하여이 문제를 처리한다.

클라이언트가 일정 기간 후에 응답을받지 못하면 클라이언트는 요청을 다시 보낸다.

 

그러나 BOOTP 클라이언트는 재전송 전략을 구현하는 방법에 주의를 기울여야 한다.

 

한가지 문제시나리오를 가정해보자.

200대의 BOOTP 클라이언트가 있는 네트워크에서, 200대의 모든 클라이언트 전원이 꺼진다고 가정하겠다.

이 기계들은 거의 모두 비슷하게(심지어 동일하게) BOOTP가 구현되었을 것이기 때문에 전원이 다시 켜지면, 모두 재시작되며 거의 동시에 BOOTP 요청을 보내려고 할것이다.

왜? 구현이 동일하니깐.

 

대부분 이러한 문제로 인해 문제가 발생할 수 있다.

BOOTP 요청 메세지 일부가 손실되기도 할것이고, 심지어 서버가 과부하로 인해 일부 메세지를 drop해야 할 수도 있다. 

서버의 패킷큐 overflow 등의 이유가 예상된다.

 

그런데 모든 클라이언트는 전송을 실패했으므로 재전송을 하려 할 것이다.

이때, 각각의 클라이언트가 재전송을 위해 동일한 시간을 기다렸다가 재전송을 하게된다면?

그 시간이 지나면 모든 기계가 요청을 다시 보낼것이므로, 동일한 문제를 반복하게 될것이다. ...야 이 멍청이들아!!??

 

이와 같은 상황을 회피하기 위해 BOOTP 표준에서는 재전송주기 시간 값을 4 초부터 시작해서, 연속 시도를 위해 이 값을 지수적인 증가, 즉 두 배로 증가, 시키는 백 오프(Back-off) 방식을 사용할 것을 권장한다.

재전송을 위해서 말이다.

또한, 여러대의 BOOTP 클라이언트가 동시에 재전송을 하는 중첩 상황을 피할 수 있게 임의성 요소가 추가된다.

이 아이디어는 이더넷(ethernet)에서 사용되는 백 오프 방법과 매우 유사하다. 실제로 BOOTP 표준은 이더넷의 사양서(Specification)를 참조한다.

 

예를 들어, 첫 번째 재전송은 0에서 4 초 사이의 임의의 시간 간격 후에 발생시킨다. (임의의 양을 더하거나 뺀 값). 

필요한 경우 두 번째 재전송에서는, 0과 8 초 사이의 임의의 시간 간격에서 플러스 또는 마이너스 하는 등...

이렇게하면 재전송이 손실되는 가능성을 줄이는 데 도움이 되며, BOOTP의 과도한 트래픽으로 인해 네트워크가 중단되지 않도록 할 수 있다.

---

DHCP

DHCP는 동적으로 Host IP 를 결정할 때 이용되는 프로토콜입니다.

동적으로 Host IP 를 결정한다는 것은 '자동으로 IP를 설정해준다' 이정도로 생각하셔도 좋을 것 같습니다.

우리가 컴퓨터를 끄거나 네트워크 연결이 끊겼다가 다시 인터넷을 쓸 때,

직접 다시 IP를 입력해주나요? 그렇지 않다. 컴퓨터가 알아서 해준다.

심지어 네트워크 연결을 처음 시도할 때도 컴퓨터가 알아서 결정해준다.

이러한 IP는 어디서 오고 누가 해주는 걸까요??

DHCP 이다.

DHCP 패킷 포맷

Op Code : 

1 or 2

1은 request, 2는 reply를 의미합니다.

 

Hardware Type :

어떤 link layer인지를 의미합니다. 대부분 Ethernet이라고 보셔도 될 것 같습니다.

(IPv6은 아에 다른 format의 DHCPv6을 사용하기 때문)

 

Hops :

DHCP relay 의 hops 를 의미합니다. (라우터의 hop이 아님!)

 

Transaction Identifier :

 UDP는 순서대로 차곡차곡 전달하는 프로토콜이 아니죠!

따라서 request와 reply의 짝을 맞춰줄 수 있는 transaction identifier가 필요합니다.

* DHCP relay란?

- DHCP는 RARP와 마찬가지로 broadcast 방식으로 request를 합니다.

하지만 DHCP가 RARP와는 달리 동일 link가 아니어도 server까지 통신이 가능했었죠!

그렇기에 DHCP relay agent 라는 router들을 거쳐 DHCP Server로 전송됩니다.

(보내는 사람 : Client

중계자들 : DHCP relay agent

목적지 서버 : DHCP Server)

 그러한 전송 과정은 unicast로 이루어집니다.

 

Seconds :

request 보내고 난 뒤 경과한 시간!

 

Flags : 

ARP 처럼 broadcast로 reply를 받겠다 : 1

unicast로 reply를 받겠다 : 0

 

CIAddr (Client IP Addr) :

아직 configured 되지 않은 경우 : 0.0.0.0

이미 configured 된 주소가 있는 경우 : 해당 IP 주소

 

YIAddr (Your IP Addr) :

서버한테 요청한 주소(요청받은 주소)

 

SIAddr (Server IP Addr) :

특정 서버를 지정하고 싶은 경우 : 해당 서버 IP 주소

그렇지 않은 경우 : 0.0.0.0

 

GIAddr (Gateway IP Addr) :

DHCP relay가 존재하는 경우 : 해당 relay IP 주소

그렇지 않은 경우 : 0.0.0.0

 

CHAddr (Client Hardware Addr) :

내가 받을 IP 주소에 매핑되는 MAC 주소입니다. 

DHCP 서버는 이 Hardware Addr 에 상응하는 IP 주소를 reply로 돌려줍니다.

 

Server Name (SName) :

Client 에게 server가 본인의 도메인 이름을 알려줄 때 사용됩니다. (그래서 64바이트나 됩니다.)

 

Boot Filename :

client의 DHCP DISCOVER 이나 서버의 DHCP OFFER에 쓰입니다.

 

Options:

매우 다양한 option이 존재합니다. 대략 200개.

예를 들자면

- DHCP Messsage Type (얘는 반드시 나온다)

- Requested IP Address (이 IP를 쓰고 싶다, 보통 쓰던거 선호)

- Host wide parameter를 가져오기.

- default router address

- DNS address

- Subnet mask 

- Parameter Request List (서버한테 원하는 것들 명시)

등등.

 

Options filed format:

첫 4바이트 : 99.130.83.99 로 시작합니다.

이것이 DHCP 의 option의 시작이라는 것을 판별해주는 것으로,

BOOTP 에서는 79.82.69.79 (O.R.E.O) 로 시작합니다.

그 뒤에는 Option 식별자 1바이트, 옵션 길이 1바이트, 옵션 데이터 순으로 이루어집니다.

 

 

DHCP message 진행 과정

DISCOVER -> OFFER  -> REQUEST -> ACK

 

(1) DHCP DISCOVER

아직 configuration 이 이루어지지 않은 상태일 때, DHCP 서버가 존재하는지 BroadCast로 물어봅니다.

(DHCP 서버를 찾는 과정입니다, client MAC 을 꼭 전달해야 합니다.)

 

(2) DHCP OFFER

서버에서 단말로 응답합니다. "나 여기 있어~" 같은 역할입니다. 

Unicast 나 Broadcast 둘다 가능하며, IP주소 뿐만 아니라 여러 데이터들도 같이 전달합니다.

 

(3) DHCP REQUEST

OFFER을 받을지 말지 결정한 후, 서버에게 요청하는 과정입니다. 본인이 사용하고 싶은 네트워크 정보를 전송하며, 

특정 서버에게 요청 가능합니다. 하지만 이 또한 BroadCast로 이루어집니다.

 

(4) DHCP ACK

REQUEST를 받아 직접적으로 네트워크 정보를 전달해주는 과정입니다.

Unicast 나 Broadcast 둘다 가능합니다.

 

 

Address lease ( 주소 임대 )

DHCP가 BOOTP와 차별화되는 가장 큰 부분입니다. BOOTP 에서는 IP binding을 사람이 직접 관리해줘야 했습니다. 

lease는 '임대' 를 의미하며, 특정 IP를 정해서 제공받는 것이 아니라, 임대 개념으로 받게 해주는 시스템입니다.

lease는 정해진 시간이 있으며, 일정 기간동안 public IP 주소를 할당해줍니다. 더 쓰려면, 그 시간이 지나기 전에 연장이 필요합니다. 그리고, 이는 보통 자동으로 이루어집니다. (일반적으로 lease time은 3600s = 1 시간)

 

 

Autoconfiguration (자동-구성)

DHCP도 운영체제 하에 자동으로 진행되지만,

Server가 없는 경우에도, 자동으로 IP를 구성할 수 있습니다.

DHCP도 안쓰고, 직접 수동으로 IP를 설정하지 않았다고 하더라도 같은 link끼리 통신을 할 수 있습니다.

이것을 해주는 것이 APIPA(Automatic Private IP Addressing) 입니다.

APIPA는 DHCP가 되지 않을 때, DHCP 서버가 없다 하더라도  private IP 주소를 자동으로 제공해줍니다.

이런 private IP 주소를 받고 난 이후에는 ARP나 ACD를 통해 중복된 주소가 있는지 DAD를 실시해줘야하고,

APIPA용으로 정해진 주소인, 169.254.0.0/16 중 하나의 주소를 부여받습니다.

이 과정을 통해 같은 링크 (255.255.0.0 의 서브넷 마스크인 곳들)와 소규모 통신이 가능하게 됩니다!