[네트워크 프로토콜] 연말행사, 함께떠나요 네트워크 프로토콜 파티 1일차(1) ARP

마지막 20대를 알차게 마무리하고, 다가오는 서른을 뜻깊에 맞이하기 위하여휴가동안 "인터넷프로토콜 핵심가이드"를 읽고 학습 및 정리하는 소박한 목표를 세워본다.

이 책은 굉장히 오래된 책이다. (국내 기준 02년 출간..) Network 프로토콜은 다른 기술 보다 변화가 상대적으로 더딘 편이지만... 그래도 감안하고 큰 개념만 익히도록 하자.

책을 읽고 이해한 내용을 바탕으로 정리한것이기 때문에 자의적인 해석이 들어가 있을 수도 있습니다. 잘못된 내용은 지적 부탁드립니다. 

/*행사일정*/
String[][] eventSchedule = 
{ 
   { "12월30일", "ARP/IGMP" } 
  ,{ "12월31일", "IP/ICMP" }
  ,{ "1월1일", "UDP/TCP" }
};

ARP

주소 변환 프로토콜은 다른 로컬 네트워크 장비의 하드웨어 주소를 파악하는 메커니즘을 제공한다.

주소변환 서비스는 IP를 지원하는 시스템에서 통신하는데 필요하다.

 

한 장비가 로컬 네트워크의 다른 장비로 IP패킷을 보내려면,

- IP 소프트웨어는 먼저 목적지 IP주소와 결합된 하드웨어 주소를 알고 있는지 확인한다. (ARP Table 뒤질듯.)

- 하드웨어 주소를 알고있으면, 송신 시스템이 두 장비간의 네트워크 매체에 적합한 프로토콜과 주소를 사용하여 목적지 시스템으로 데이터를 전송한다.

- 목적지 시스템의 하드웨어 주소를 알 지 못하면 IP소프트웨어는 데이터를 보내기 전에 하드웨어 주소를 먼저 파악해야 한다.

-> 즉, IP는 이 시점에서 목적지 시스템의 하드웨어 주소(MAC)를 파악하기 위하여 ARP를 호출한다.

 

ARP의 대략적인 동작은,

1) A는 IP주소가 192.168.10.40인 호스트의 MAC주소를 찾는 ARP request를 브로드캐스트 주소로 보낸다.

2) IP주소가 192.168.10.40인 B는 자신의 MAC 주소를 담은 ARP response를 A에게 보낸다.

3) A가 B의 MAC주소를 파악하면, A는 B에게 보낼 데이터를 B의 MAC주소로 보낼 수 있게 된다.

 

ARP 패킷은 IP패킷과 마찬가지로 데이터 링크 계층과 직접 통신한다.

ARP패킷 헤더에서 주소와 관련된 필드는 아래의 내용을 포함한다.

- 자신의 IP주소 && MAX주소 && 목적지의 IP주소 (목적지의 MAC주소는 알 수 없으므로 모두 0으로 채운다.)

- 또한 메시지 종류 필드를 현재의 패킷이 ARP 요청이라는 것을 나타낸 다음, 그것을 모든 장비가 알아챌 수 있도록 로컬 네트워크에 흩뿌린다.

 

ARP 요청을 받는 모든 로컬 장비에서는,

브로드캐스팅 방식으로 전달되는 ARP 요청을 감시하기 위해 네트워크를 항상 감시하고 있다가

목적지 IP주소 가 자신에게 보내는 요청임을 알게되면, ARP 응답패킷을 생성하여 요청 시스템에 보내야 한다.

응답 패킷은 송신자 필드에 자신의 IP주소와 MAC주소를 포함하고, 목적지에 요청시스템의 IP주소와 MAC주소로 구성되는것이 일반적이며, 경우에 따라서는 현재의 패킷이 'ARP 응답'임을 표시하는 메시지 종류 필드를 설정하여 응답임을 나타낼 수도 있다.

이렇게 생성된 새로운 응답 패킷은 브로드 캐스팅 방식이였던 'ARP request' 패킷과는 달리 ARP request 패킷을 보낸 호스트에게만 직접 전송(유니캐스트) 요청 시스템은 이를 수신하여 처리한다.

 

ARP요청의 특징은,

ARP요청에는 timeout이 적용되지 않는다. 응답이 돌아오지 않아도 ARP는 신경쓰지 않는다.

응답이 끝까지 돌아오지 않으면 IP스택에서는 계속 ARP 요청을 전송한다. 하지만 이것은 ARP의 구현과 질의 방식에 따라 달라진다. 

 

궁금하지 않나요, ARP Request에 응답하지 않을경우 어떤일이 일어나는지.

대부분의 경우, ARP탐색 큐에는 각각의 질의 대상 호스트마다 하나의 패킷을 저장할 수 있는 공간만 남아있다.

ARP 요청에 응답이 없으면 IP에서 질의 대상 호스트를 향한 새로운 패킷이 도착하여, 첫번째 질의는 중단되고

두번째 질의가 일어난다. 이 단계에서 호스트가 ARP질의에 응답하지 않고 있는데도 IP가 그 호스트로 여러개의 데이터그램을 보내려 시도하면 그 호스트로 향하는 질의가 여러 개 생겨난다.

 

이런 경우, TCP와 같은 상위 계층 프로토콜이 이런 문제를 감지하고 재전송을 시도하여, 또 다른 IP패킷을 생성하는(또다른 ARP 패킷요청을 생성하는) 결과를 낳을 수 있다. 반면 UDP나 ICMP같은 다른 프로토콜은 재전송을 시도하지 않고 실패한 ARP탐색을 단순히 일반적인 타임아웃 오류(타이머가 있을 경우)로 간주할 뿐이다.

 

예를들어, 네트워크 관리자가 핑을 특정 호스트에 날렸는데, 호스트가 알수없는 장애가 발생하여 ARP브로드캐스트에 응답하지 못하면 ICMP Echo Request 메시지또한 받을 수 없을 것이다. 하지만 핑은 응답없는 호스트를 향해 계속해서 ICMP Echo Request메시지를 생성할것이고, 또한 ARP 탐색(Lookup)패킷을 생성할 수도 있다.

 

하지만 오류의 원인이 ARP가 아닌 핑 프로그램에 있어도, 핑은 관리자에게 실패한 각각의 탐색에 대해 시간초과 오류를 보고한다.

--> ?? 무슨말인가. ARP요청에 응답이 없을때, TCP는 재전송을 시도하여 또다른 IP패킷을 생성(물론 또다른 ARP 패킷 생성) 할수 있다 반면 UDP나 ICMP는 재전송을 시도하지 않고 ARP요청을 타임아웃으로 간주한다는것? 패킷이 유실 될 수 있다는건가.

 

ARP 캐시

ARP 요청을 보냈던 시스템은 ARP응답을 수신하면 목적지 시스템의 MAC주소와 IP주소를 로컬 캐시에 저장한다.

그리고 다음번에 데이터를 보낼 때 로컬 캐시를 먼저 검사하고 엔트리를 찾으면 그것을 사용한다! 

 

또한 ARP브로드캐스트에 응답하는 시스템도 브로드캐스트를 보낸 시스템의 하드웨어 주소와 IP주소를 지정한다. 그렇게 하지 않는다면, 응답 시스템에서는 데이터를 받고나서 송신자에게 응답을 보낼때 마다 MAC주소를 알아내기 위하여 ARP브로드 캐스트에 의존해야 한다.

 

네트워크의 모든 시스템에서 ARP브로드캐스트를 수신하므로, 시스템들은 송신시스템의 IP주소와 MAC주소를 캡처하여 캐시에 저장 할 수있다.

but! 기존의 ARP엔트리를 덮어 쓸 수 있으므로, ARP테이블에 이미 IP주소를 갖고있을때에만 캐시를 갱신해야 한다. 

==> ARP테이블에 IP/MAC엔트리가 있다고 하자. 만약 새로운 ARP Request에 동일IP/다른 MAC주소가 들어오면 어떻게 동작을 할까? 그냥 ARP캐쉬를 업데이트 하나? --> 캐시의 시간초과 항목을 참고한다.

네트워크에 동일한 IP를 가진 호스트가 2대 이상일때(흔히 말하는 IP충돌) 정상적으로 통신 할 수 없는건 이런 문제인가?!

 

캐시크기

대부분의 시스템은 몇개의 엔트리만 저장할 수 있을 정도로 아주 제한적인 ARP캐시를 갖고 있다. 이러한 제약사항은 경우에 따라서 엔트리 교체가 빈번히 일어나 작은 부하를 일으키기도 한다.

 

예를들어 하나의 클라이언트 시스템이 다양한 서버에 자주 접근하는데 클라이언트시스템의 ARP캐시가 접속하고 있는 서버의 수보다 작다면, (ARP테이블에 저장 할 수 있는 용량이 서버의 개수보다 작다면) 당연하게도 이 시스템에서는계속해서 캐시의 엔트리를 교체해야 한다. (더 자세히는 ARP브로드캐스트를 보내 그 결과를 캐시에 저장하지만 얼마 지나지 않아 또 다른 ARP 브로드캐스트의 결과로 교체된다.) 

 

이러한 문제는 반대로 다수의 클라이언트가 하나의 서버에 접근할때 서버의 ARP캐시가 모든 클라이언트의 ARP엔트리를 저장하기에 너무 작다면, ARP캐시는 계속해서 갱신되어야 할것이다.

 

대형 멀티 유저 시스템과 라우터는 대다수가 아주 큰 ARP캐시를 사용하여 이런 문제가 발생하지 않도록 하고 있다.

==> ARP캐쉬 사이즈를 설정할 수 있는 옵션이 있을것 같다.

 

캐시의 시간 초과

어떤 ARP엔트리가 한동안 사용되지 않으면, 시스템은 ARP캐시에서 그 엔트리를 교체한다. 이는 엔트리의 저장된 IP주소를 다른 장비에서 사용 할 수도 있고, 또 엔트리에 저장된 장비가 새로운 IP주소로 할당받아 통신할 수도 있기 때문이다. ARP캐시의 시간 초과 값이 너무 길게 설정되면, 캐시의 오래된 엔트리를 참고하여 문제를 일으 킬 수도 있다.

 

반대로 ARP캐시의 시간 초과 값을 너무 낮게 설정해도 많은 장비들이 물려있는 네트워크에 문제를 유발한다. 지속적으로 ARP 캐시의 엔트리를 교체하게 되고, 많은 브로드캐스트를 전송하게 되기 때문이다. 이는 IP소프트웨어에서 ARP 브로드캐스트를 전송하고 응답을 수신할 때까지 데이터를 전송하지 못하므로 결과적으로 네트워크의 성능이 떨어지게 된다.

 

RFC 826에서는 ARP캐시 엔트리에 대해 특정 timeout 값을 규정해 놓지 않았으므로, 공급업체들마다 서로 다른 값을 사용하고 있다. 

(책에는 운영체제나 라우터 별로 timeout값을 안내하고 있지만 너무 오래된 내용이라 이는 생략한다.)

 

정적캐싱

엔트리가 만료되고 교체되면서 발생하는 문제를 해결하기 위하여, 많은 제품이 캐시에 만료되지 않는 정적 엔트리를 추가하는 도구를 제공한다. 일부 시스템은 시스템이 다시 시작될 때 정적 엔트리를 삭제하여 다시 추가해야 하지만, 반영구적으로 캐시에 보존하는 시스템도 있다.

 

시스템이 자주 이전되거나 시스템의 주소가 바뀌는 환경에서는 관리하기 어렵다.

서버의 네트워크 어댑터가 바뀌거나 잘 알려진 IP주소가 다른 컴퓨터로 옮겨지면 그 장비에 대한 정적 캐시 엔트리는 모든 시스템에서 유효하지 않게 된다. 따라서 정적 캐시 엔트리가 삭제되지 않는 한, 모든 시스템은 그 장비와 통신을 하지 못하게 된다.

 

정적 ARP 엔트리 사용시 이점

- 중요한 호스트의 IP주소를 사용해서 접근하려는 시도를 막을 수 있다. 물론 고정IP일때 사용할 수 있겠지

- 클라이언트 들이 자주 사용하는 서버에 대한 엔트리를 저장 하여 ARP탐색빈도를 줄일 수 있다.

 

프록시 ARP

경우에 따라서는 한 장비가 다른 장비를 대신하여 ARP브로드캐스트에 응답하도록 하는것이 유용하다. 

이하는 전화접속네트워크(!)라는 암모나이트급 유물을 예로 들고 있으므로 생략한다.

+검색 후 내용 추가 필요

 

ARP의 변형

IP장비가 특정 IP주소의 MAC주소를 파악 할 수 있듯이, 특정 MAC주소를 가지고 있는 호스트의 IP주소도 파악 할 수 있다.

- Inverse ARP : ARP와 정 반대로 동작한다. 하드웨어 주소와 결합된 IP주소를 찾는데 사용된다.

- Reverse ARP : 디스크가 없는 단말이 ARP요청에 자신의 MAC주소를  브로드캐스팅 하여 Reverse ARP서버에서 이 요청을 수신하면 요청 시스템에서 사용할 수 있는 IP주소를 포함한 ARP응답을 생성하여 요청 시스템에 전송한다. 

+ IP주소 이외의 추가정보를 얻을 수 없어 잘 사용하지 않고 대신 BOOTP또는 DHCP를 많이 사용한다.

 

- DHCP ARP

DHCP ARP는 DHCP등과 같은 주소 할당 프로토콜을 사용하여 IP주소를 할당받는 장비에서 사용된다. DHCP ARP의 목적은 장비가 할당받은 주소를 사용하기 앞서 다른 장비에서 그 주소를 사용하고 있는지 판단하기 위해 네트워크를 조사 하는데 있다. 이 과정은 다른 시스템에서 DHCP ARP 질의에 응답하면 요청 시스템에서 할당받은 IP주소의 사용을 거부 할 수 있으므로, IP주소가 중복되어 할당되는 것을 방지한다.

 

Gratious ARP

장비가 ARP브로드 캐스트를 통해 다른 장비에게 네트워크에 있는 자신의 존재를 알리는 목적으로만 사용된다. 네트워크의 이 장비에 대한 엔트리를 갖고 있는 장비들은 자신의 ARP캐시를 갱신하여 이 장비의 엔트리가 만료되지 않도록 한다.

 -> 혹은 강제로 갱신한다? 예를들어 HA구성에서 Active상태의 장비가 죽고 Standby장비가 통신해야 할때.. Standby 장비는 Gratuitous ARP 를 사용해서 네트워크 내의 다른 단말들에게 ARP 테이블에서 Active가 아닌, 자신을 가리키도록 갱신해야 할것이다.

 

- UnARP

+내용 추가 필요

 

Inverse ARP

- ARP와 정 반대로 동작한다. 즉 시스템이 인지하고 있는 데이터 링크 주소를 통해 그와 맵핑되어있는 IP주소를 파악 할 수 있도록 한다. 이는 장비들이 데이터 링크 계층에서는 서로 인지하지만, 서로의 IP주소를 몰라 IP를 사용하여 통신하지 못하는 경우에 Inverse ARP기능이 필요해진다. 이런 상황은 프레임 릴레이나 ATM처럼 다른 물리 네트워크를 통합하여 데이터 링크 주소를 공유하는 네트워크에서 흔하게 발생한다.

 

여기서 잠깐, Inverse ARP랑 RARP 비슷한것 같은데?!

알아보기 전에 "Frame Relay"에 대해 알 필요가 있다. Frame-relay는 L2계층의 프로토콜로, X25를 기반으로 하고 있다.

X25란 패킷 교환망에서 DCE와 DTE사이에 이루어지는 상호 작용을 규정한 프로토콜이다.

 

출처 : https://unabated.tistory.com/entry/X25-%EC%99%80-TCPIP

TCP/IP	X25
RARP	Inverse ARP
L2(MAC) 주소를 가지고 있지만, 상대방의 L3 주소를 모를때	L2(DLCI) 주소를 가지고 있지만, 상대방의 L3 주소를 모를때

프레임 릴레이 네트워크는 장비 자체가 하드웨어 주소를 갖지 않는다는 점에서 선형적인 네트워크와 다르다. 프레임 릴레이 네트워크에서는 장비가 연결된 각 회선에 대한 주소(데이터 링크 회선 식별자 DLCI 주소로 알려져 있음.)를 갖는다. 장비가 다른 장비로 데이터를 전송할 때마다 목적지 장비에 도달할 수 있는 특정 회선에 결합된 DLCI주소로 데이터를 전송한다.

 

IP의 관점에서는 어떤 장비가 프레임 릴레이 네트워크의 다른 장비에 IP패킷을 보내는 경우, 송신 장비는 올바른 프레임 릴레이 회선을 통해 알려진 IP주소로 데이터를 보낼 수 있도록 IP주소를 특정 회선 식별자에 대응하는 ARP캐시를 갖고 있어야 한다.

=> 자세히 모르겠다..

 

Reverse ARP

Reverse (RARP)는 영구적인 IP주소가 없거나 영구적인 IP주소를 종류별로 구분하기에는 자원이 충분하지 않은 단말기에서 사용한다. 

이런 장비는 자신이 사용할 IP주소를 할당받으려고 할 때 (보통 부팅시)마다, 송신자 및 수신자 하드웨어 주소 필드에 자신의 하드웨어 주소를 저장하여 ARP브로드캐스트를 전송한다. 송싱자 및 수신자 프로토콜 주소는 0으로 채워진다.

 

특정 호스트(RARP 서버 라고 불리는)에서 RARP 브로드 캐스트를 감시한다. 서버는 RARP 브로드캐스트를 수신하면 요청한 장비의 하드웨어 주소에 대한 엔트리를 자신의 IP대 하드웨어 주소 대응표에서 찾는다. 엔트리가 검색되면, 서버는 요청 장비에 부팅을 계속하는 데 필요한 IP주소를 담은 RARP 응답을 요청 장비에 보낸다.

하지만 네트워크에서 사용하는 서브넷 마스크를 자동으로 결정하는 기능이나, 사용 가능한 라우터에 관한 정보는 제공하지 않는다. 이런 이유로 많은 장비들이 오래 전부터 주소 할당과 설정 서비스에 BOOTP나 DHCP설정 프로토콜을 사용하기 시작했고 RARP는 오래된 장비가 많은 네트워크에서나 찾아볼 수 있다.

 

DHCP ARP

DHCP가 RARP와 다른 중요한 차이 가눙데 하나는 공유되는 주소의 목록에서 주소를 할당한다는 것이다.

이는 각 호스트마다 하나의 고정된 주소를 할당하는 것이 아니라 적은 수의 IP주소를 많은 수의 호스트에서 공유 할 수 있게 한다.

한편 이런 특징은 관리 업모를 하기에는 편리 할 수 있지만, 여러개의 장비가 동시에 같은 주소를 사용하지 않도록 해야 한다는 점에서는 오히려 관리하기가 어려울 수 있다.

특히 DHCP주소 목록에서 이미 할당된 주소를 다른 사용자가 수동적으로 동일한 IP을 설정 하는 경우에 문제가 된다.

 

문제가 발생하는 경우를 최소화 하기 위해서 RFC 2131(DHCP RFC)은 장비가 DHCP서버에서 할당한 주소를 받아들이기 이전에 결점이 없는지 검사하도록 규정하고 있다.

 

DHCP ARP를 요청하는 장비는 출발지 IP필드에 자신의 IP주소 대신 '0.0.0.0'을 저장한 일반 ARP요청을 전송한다. 패킷의 나머지는 일반 ARP요청과 같이 출발지 하드웨어 주소 필드에 로컬 하드웨어 주소를, 목적지 IP필드에 질의대상 IP주소를 저장하고 목적지 하드웨어 주소 필드에는 0으로 채운다.

 

 

 

 

 

 

 

 

 

 

 

 

 

이런 필드의 조합은 두가지 목적을 만족시킨다

1) 출발지 하드웨어 주소 필드에 로컬 하드웨어 주소를 제공함으로써, 질의 대상 주소를 이미 사용하고 있는장비는 ARP 요청을 수신하여 응답할 수 있다. 그러니까. ARP에 응답이 온다면 그 IP는 누가 사용하고 있는것이지. IP충돌을 막을 수 있다.

2) 출발지 IP주소가 0.0.0.0이므로 네트워크의 다른 시스템들이 자신의 ARP캐시를 갱신하는 것을 막는다. 그렇지 않으면 네트워크의 다른 장비는 IP주소를 이미 사용하고 있어도 자신의 캐시에 출발지주소 IP의 주소를 ARP 캐시에 업데이트 하게 된다. (하지만 모든 장비가 그러한것은 아니다. 대부분의 오래된 시스템은 출발지 IP가 0.0.0.0으로 채워진 ARP 요청을 무시한다...)

 

하지만 클라이언트가 DHCP ARP 요청에 대해 응답을 받지 않았다고 해서 그 IP주소가 사용하기에 안전한 것은 아니다. 예를들어 해당하는 IP주소를 영구적으로 사용하는 어떤 장비에서 DHCP ARP요청이 전송된 그 순간에 잠시 전원이 꺼져 있을 수 있다. 따라서 그 장비에 다시 전원이 들어오면 자신이 영구적으로 할당받은 주소를 사용하려고 할 것이며, 이는 주소 충돌 문제를 일으키게 된다. (후 산넘어 산이구나...) 

 

Gratutitous ARP

Gratutitous ARP요청이 브로드캐스트되면, 송신 시스템은 자신의 하드웨어 및 IP주소 정보를 송신자 필드에 저장하고, 목적지 IP주소 필드에도 자신의 IP주소를 저장한다. 그러나 목적지 하드웨어 주소에는 자신의 하드웨어 주소를 저장하지 않는다.

Gratutitous ARP 요청을 수신한 네트워크의 다른 장비들은 송신자 정보가 자신의 캐시에 이미 존재하는 경우, 그 엔트리에 대한 타이머를 초기화하거나, 새로운 하드웨어 주소로 수정한다. (송신 호스트의 네트워크 어댑터가 바뀐 경우가 Gratutitous ARP패킷을 날리는 경우에 해당한다.)

 

만약 어떤 시스템에서 Gratutitous ARP브로드캐스트에 응답하면, 그 시스템은 송싱자 시스템과 같은 IP주소를 사용하고 있다는 것을 뜻한다. 이런 경우 두 시스템은 주소 충돌이 발생한 것을 인지하고, 다른 호스트에서 로컬 호스트의 IP주소를 사용하고 있다는 경고 메시지를 표시할 수도 있다.

 

많은 호스트가 이런 목적으로 온라인 상태가 되자마자 간편하게 주소충돌을 검사하는 Gratutitous ARP를 사용한다. 그러나 이렇게 Gratutitous ARP를 사용하는것은 문제를 일으킬 가능성을 내포하고 있다. 예를 들어, 잘못 설정된 호스트가 다른 시스템에서 이미 사용하고 있는 IP주소에 대해 Gratutitous ARP를 전송하면?! 이를 수신한 모든 클라이언트는 새로운 하드웨어 주소로 자신의 ARP캐시를 갱신한다. 그순간부터 캐시 엔트리가 갱신될 때까지 클라이언트는 원래의 호스트가 아닌 잘못 설정된 호스트로 데이터를 전송하게 된다. (끔찍) 

 

시작 시점에서 주소 충돌을 검사하기 위한 방법으로 DHCP ARP를 사용하는것이 어떤면으로 나을 수 있다. 이는 DHCP ARP를 통해 송신 시스템이 IP주소를 실질적으로 사용하기에 앞서 그 IP주소가 다른 시스템에 의해 사용되는지 여부를 감지할 수 있기 때문이다. + Source Protocol Address필드를 0으로 채우면 다른 시스템이 자신의 ARP 캐시에서 이 호스트에 대한 정보를 갱신하는 것을 막을 수 있기 때문이다.