◦ TCP/IP 주소 결정
- ARP (Address Resolution Protocal) : 주소 결정 프로토콜
: IP 주소에 대응되는 Ethernet의 하드웨어 주소(MAC)를 알아냄
: 논리적 주소(IP)->물리적 주소(MAC)
: 상대방이 MAC 주소가 없는 패킷을 받으면 Datelink Layer에서 폐기함
: MAC 주소를 알아야 프레임이 만들어져서 통신이 가능(IP Datagram을 캡슐화하기 때문)
: 3계층끼리 연결돼있는 것처럼 보이지만 2계층을 거침
- ARP 트랜잭션
1) 출발지 장비가 캐시를 검사
2) 자신의 데이터 링크 계층 주소를 Sender Hardware Address(SHA)로, 자신의 IP 주소를 Sender Protocal Address(SPA) 필드로, 목적지 IP 주소를 Targer Protocal Address(TPA) 필드에 넣는다
3) 출발지 장비가 브로드캐스트
4) 로컬 장비들이 ARP 요청 메시지를 처리 : 내용을 보고 TPA와 자신의 IP가 일치하는지 확인
5) ARP 요청 메시지를 SHA와 SPA 필드의 값을 응답 메시지의 THA와 TPA 필드 값으로 이용. 그리고 자신의 2계층
주소를 SHA에, 자신의 IP 주소를 SPA 필드에 채운다
6) 성능 향상을 위해 자신의 ARP 캐시에 ARP 요청을 보낸 출발지의 장비의 MAC와 IP 주소 추가
7) 출발지 장비에만 유니캐스트
8) 응답의 SHA를 목적지 장비의 2계층 주소로 인식
9) SPA 와 SHA를 이용해 자신의 ARP 캐시를 갱신
: ARP로 패킷을 브로드캐스팅을 자주 할 경우 네트워크 트래픽이 증가 => 캐시정보를 이용하기 때문
: 송신 Host가 ARP Request 패킷을 브로드캐스팅할때 패킷을 수신한 모든 Host는 송신 Host IP주소와 MAC 주소 Mapping 값을 자동으로 얻음 => 트래픽 최소화
- Proxy ARP
: 물리적으로 다른 네트워크이면 ARP 메시지를 주고 받을 수 없음
(3계층에선 동일 네트워크지만 2계층(데이터링크)에선 서로 다른 네트워크일때)
=> 라우터가 프로싱 해서 해결
- RARP (Reverse Address Resolution Protocal) : 역순 주소 결정 프로토콜
: ARP와 동일하게 작동, 다만 방향이 반대
: MAC 주소를 담은 요청(브로드캐스트)을 보내고 RARP 서버가 IP로 응답
: RAPR 서버를 운영 -> 중앙관리가 어려움
: HOST 에게 IP 주소만 응답해줌 -> 서브넷마스크나 기본 게이트웨이 정보를 받을 수 없음(제한된 정보)
: 수동으로 Mapping 해야됨 (또한 RAPR 서버별로 이루어져야됨)
: 단점이 많아서 잘 안쓰임 -> BOOTP DHCP로 대체됨
참고
