제 16 장 BOOTP

목 차 개 요 BOOTP 패킷형식 예 BOOTP 서버 설계 라우터를 경유하는 BOOTP 벤더-사양정보 요 약

개 요 디스크 장치가 없는 시스템이 초기 가동 시에 자신의 IP주소를 얻기 위해 RARP의 대용으로써 개발된 프로토콜 개 요 디스크 장치가 없는 시스템이 초기 가동 시에 자신의 IP주소를 얻기 위해 RARP의 대용으로써 개발된 프로토콜 RARP와의 차이 IP 주소 이상의 정보 전달 가능 Router를 통과해 전송이 가능 RARP가 오직 IP세션만을 이용하는 것과는 달리 BOOTP는 UDP세션 을 이용하여 IP주소를 알아낼 수 있고 , 크기도 작아 응용프로그램과 함께 사용 UDP를 사용하고 TFTP와 결합되어 사용 RFC 951

UDP/TCP UDP(User Datagram Protocol) TCP(Transmission Control Protocol) UDP사용 application프로그램들은 할당된 UDP포트를 이용해 통신 대표적인 application : NFS, DNS, BOOTP, SNMP etc. TCP와 달리 신뢰성은 부족하지만 UDP구조가 TCP보다 훨씬 단순화되어 있기 때문에 빠른 전송이 가능 TFTP 사용 단지, 메시지를 Broadcasting 함 - 따라서 Network가 혼잡하거나 Routing이 복잡할 경우 Network상의 패킷이 유실될 우려가 있음 UDP패킷에 시간 제한을 두어 네트워크 패킷 손실을 보완하려는 많은 알고리즘이 개발 TCP(Transmission Control Protocol) rlogin, FTP, SMTP etc.

BOOTP의 패킷 형식 (1) UDP 데이타그램의 BOOTP요구와 응답의 캡슐화 IP datagram UDP datagram BOOTP message IP header UDP header BOOTP request/reply 20 8 300 UDP 데이타그램의 BOOTP요구와 응답의 캡슐화

BOOTP의 패킷 형식 (2) <BOOTP 요구와 응답 형식> 1 1 1 1 opcode req=1, rep=2 hardware type ethernet=1 hardware address length(ethernet=6) hop count transaction ID number of seconds unused client IP address your IP address 300 bytes server IP address gateway IP address client hardware address (16 bytes) server hostname (64 bytes) boot filename (128 bytes) vender-specific information (64 bytes) <BOOTP 요구와 응답 형식>

BOOTP의 패킷 형식 (3) opcode : request(1), reply(2) hardware type : ethernet(1) hardware address length : ethernet(6) hop count : hop counting for proxy server. transaction ID : request/reply 적합여부 판단, random number number of seconds : starting bootstrap time(by client). client IP address : client’s IP address(by client). your IP address : client’s IP address(by server). server IP address : server’s IP address(by server). gateway IP address : proxy server IP address. client hardware address server host name boot filename vendor-specific area : various extensions to BOOTP.

포트 번호 (1) 서버 : 67번, 클라이언트 : 68번 클라이언트와 서버 모두 지정 번호를 가지는 이유 서버 : 67번, 클라이언트 : 68번 클라이언트와 서버 모두 지정 번호를 가지는 이유 서버가 응답을 broadcast로 보내기 때문 Server의 응답이 broadcast되고, client가 임시 포 트 를 선택하면 우연히 같은 포트를 사용한 다른 host의 응용에 의해서 broadcast가 수신될 수 있다. 따라서 임의의 포트번호로 broadcast하는 방법은 좋지 않 음

포트 번호 (2) 클라이언트가 서버의 잘 알려진 포트(67)를 사용하면 여러 클라이언트들이 동시에 초기 가동되고, 서버가 네트워크상의 모든 서버가 각 broadcast 응답에 반응 만약, 모든 서버가 반응하면 이들은 opcode 를 검사하고 이것이 요구가 아닌 응답을 알고 동작을 중단 여러 클라이언트들이 동시에 초기 가동되고, 서버가 응답을 broadcast 한다면 각 클라이언트는 다른 클라이언트로 가는 응답을 보게 됨 클라이언트는 transaction ID필드에서 요구와 응답이 적합한 것인가를 판단 돌아온 client의 hardware 주소를 검사

BOOTP 사용의 예 (1) 1 0.0 0.0.0.0.68 > 255.255.255.255.bootp: secs:100 ether 0:0:a7:0:62:7c 2 0.355446 (0.3554) mercury.bootp > proteus.68: secs:100 Y:proteus S:mercury G:mercury ether 0:0:a7:0:62:7c file “/local/var/bootfiles/Xncd19r” 3 0.355447 (0.0000) arp who-has proteus tell 0.0.0.0 4 0.851508 (0.4961) arp who-has proteus tell 0.0.0.0 5 1.371070 (0.5196) arp who-has proteus tell proteus 6 1.863226 (0.4922) proteus . 68 > 255.255.255.255.bootp: 7 1.871038 (0.0078) mercury.bootp > proteus.68: secs:100 Y:proteus 8 3.871038 (2.0000) proteus . 68 > 255.255.255.255.bootp:

BOOTP 사용의 예 (2) < X터미널의 초기 가동 시에 사용된 BOOTP의 예 > 9 3.878850 (0.0078) mercury.bootp > proteus.68: secs:100 Y:proteus S:mercury G:mercury ether 0:0:a7:0:62:7c file “/local/var/bootfiles/Xncd19r” 10 5.925786 (2.0469) arp who-has mercury tell proteus 11 5.929692 (0.0039) arp reply mercury is-at 8:0:2b:28:eb:1d 12 5.929694 (0.0000) proteus.tftp > mercury.tftp: 37 RRQ “/local/var/bootfiles/Xncd19r” 13 5.996094 (0.0664) mercury.2352 > proteus.tftp: 516 DATA block 1 14 6.000000 (0.0039) proteus.tftp > mercury.2352: 4 ACK many lines deleted here 15 14.980472 (8.9805) mercury.2352 > proteus.tftp: 516 DATA block 1 16 14.984376 (0.0039) proteus.tftp > mercury.2352: 4 ACK 17 14.984377 (0.0000) mercury.2352 > proteus.tftp: 516 DATA block 2464 18 14.984378 (0.0000) proteus.tftp > mercury.2352: 4 ACK < X터미널의 초기 가동 시에 사용된 BOOTP의 예 >

BOOTP 사용의 예 (3) 라인1 : client의 request ( 0.0.0.0.68 -> 255.255.255.255.bootp ) 라인2 : server의 reply 라인3-5 : 응답을 받은 후, client는 ARP요구를 발행 송신자의 IP주소를 0.0.0.0설정 -> 자신의 IP주소로 변환 (불필요한 ARP요구) 라인6-9 : 또 다른 BOOTP 요구를 broadcast 하고, 응답을 받는다. 라인10 : ARP요구 라인11 : ARP 응답이 수신 라인12 : client는 즉시 가동 파일을 읽는 TFTP요구를 발행 라인13-18 : 2464TFTP 데이터 패킷과 이의 확인 응답 전송된 데이터(512*2463+224=1,261,280byte)에 의해 X터미널에 운영체제가 적재

BOOTP 사용의 예 (4) Client는 모든 전송에 TFTP의 잘 알려진 포트(69)을 이용 tcpdump는 패킷이 TFTP메시지라는 것을 인식하고 각 패킷을 해석 일반적으로, 클라이언트가 이 포트(69)를 사용 못함 그러나 여기서 시스템은 초기 가동 중에 있고, TFTP서버는 제공되지 않고 있어 그 포트(69)를 사용할 수 있다. 이것은 TFTP서버가 client의 포트번호에 대해 상관하지 않는다는 것

BOOTP Server Design (1) BOOTP client는 보통 디스크 없는 시스템에 ROM으로 제공 서버는 well-known port(67)로 부터 UDP datagram을 읽음 서버는 BOOTP 패킷으로 부터 클라이언트의 하드웨어 주소를 쉽게 얻을 수 있다(not RARP). 문제 Server는 응답을 어떻게 해서 client에게 직접 되돌릴 수 있는가 ? 응답은 UDP datagram이고, 서버는 client의 IP주소를 알고 있음 그러나, Client가 UDP datagram을 그 IP주소로 보낸다면, 서버의 호스 트는 IP주소에 대한 ARP요구를 발행 그러나, Client는 아직 자신의 IP주소를 모르기 때문에 ARP요구에 대해 서 응답 못함.

BOOTP Server Design (2) 해결방법 Server가 커널에 대해 ioctl() 요구를 발행하고 client의 entry를 ARP Cache에 위치 시킴 Server가 client의 H/W주소와 IP주소를 알고 있기 때문에 Server가 UDP Datagram 을 전송할 때 Server의 ARP모듈은 ARP Cache에서 Client의 IP주소를 찾을 수 있음 Server가 직접 Client에 BOOTP 응답을 전송하는 것이 아니라, Broadcast 하는 것 Server가 ARP Cache에 entry를 만들 수 없는 경우에만 이용 일반적으로, ARP Cache에 entry를 작성하기 위해 Super User 권한이 요구 (만약, 그렇치 않으면 Broadcast 응답이 요구)

BOOTP relay agent(라우터) 부트스트랩 요청을 라우터를 통해 다른 network에 요청 가능 일반적인 UNIX의 BOOTP 서버는 이 중계모드를 지원하지만, 물리 네트워크에서 BOOTP서버를 실행할 수 있다면 다른 네트워크상의 서버에 요구를 전송할 필요가 없다. 라우터 통과시 hop count field를 1 증가하고 3 되면 패킷 소멸. 송신하는 요구는 unicast datagram이기 때문에 다른 Router를 경유해서 실제 BOOTP 서버까지 하나의 경로를 가짐 서버는 요구를 받고 BOOTP응답을 생성  Router에 응답  Client에 전송

Vendor-specific information (1) RFC 1533 추가적인 정보를 저장하는 부분 99.130.83.99의 IP 주소로 설정 (이 영역의 처음 4byte) 종류 pad : 다른 정보와의 경계 명시, tag 0. subnet mask : 하위 network의 mask 정보 명시, tag 1, 4bytes. time offset : 1900, 1월 1일 자정으로부터의 시각 명시, tag 2, 4bytes. gateway : 데이터의 길이는 항상 4의 배수로써 클라이언트가 사용하는 라우터 의 IP 주소 명시, tag 3, N bytes. end : 정보의 끝 명시, tag 255.

Vendor-specific information (2) 14 other items. DNS 이름 서버의 IP주소 (tag 6), 프린터서버, 타임서버의 IP주소 자신의 subnet Mask를 찾기 위해 client에 의해 broadcast 되는 “ICMP주소 마스크요구”를 결코 보지 못했음 Client의 서브 넷 마스크는 BOOTP응답에 있는 벤더-사양 영역에 되돌아 온 것으로 생각 DHCP(Dynamic Host Configuration Protocol)에 의한 길이 확장(312 bytes) BOOTP를 대체하는 프로토콜로 주목

요 약 BOOTP는 UDP를 사용하여 디스크 없는 시스템의 부트스트랩 파 일의 전송을 수행 요 약 BOOTP는 UDP를 사용하여 디스크 없는 시스템의 부트스트랩 파 일의 전송을 수행 디스크가 없는 시스템은 읽기 전용 메모리에 BOOTP, TFTP, UDP, IP, device driver 등을 필요로 함. BOOTP 서버의 구현은 RARP 서버의 구현보다 쉬운데, BOOTP request, reply가 link-layer frame이 아닌 UDP datagram 안에 존재하기 때문 Datagram이 proxy agent인 라우터에 의해 forwarding이 가능