[Network] ICMP 관련 정보, MTU 설정 관련 정보들 조회(99)

[Network] ICMP 관련 정보, MTU 설정 관련 정보들 조회(99) 상식 | 2005/09/08 (목) 11:57 추천(0) | 스크랩(0) Packet // Fragment   DF, Path MTU Discovery (PMTU-D) ICMP(8Bytes ) Filtering시 일어나는 문제점... ==> 큰 단위의 파일 전송에서 일어나는 문제점.   정보에 대한 심화 정보는 실제 코드가 필요할 때 더 찾아보길..     ===================================================== 출처 - pc사랑 (http://www.ilovepc.co.kr/record_detail_read.php?NO=9368&MOM_TITLE_NO=9366) 더 빠른 인터넷을 위한 레지스트리를 만들자 윈도우즈 레지스트리는 윈도우즈를 운영하기 위한 정보를 담고 있다. 윈도우즈에 깐 소프트웨어나 하드웨어에 대한 정보는 물론 윈도우즈 옵션도 레지스트리에서 손 볼 수 있다. 초고속 인터넷의 속도를 200% 올릴 수 있는 네트워크 옵션도 레지스트리에서 정한다. ADSL과 케이블 모뎀을 위한 특별한 레지스트리를 만들자. 네트워크 옵션을 왜 바꿔야 하나요? 인터넷은 데이터를 주고받기 위해 TCP/IP 프로토콜을 쓴다. TCP/IP 프로토콜은 데이터 한 개를 작은 데이터 여러 개 묶음으로 잘라서 이 묶음을 내가 통신할 상대와 주고받는다. 이 작은 데이터 꾸러미를 패킷이라고 하는데 패킷의 최대 크기를 MTU(maximum transmission unit : 최대 전송 단위)라고 한다. 최대 MTU 크기는 1,500바이트다. MTU 값이 클수록 실어 나를 수 있는 데이터 크기가 커진다. 1톤의 짐을 나를 수 있는 트럭과 1.5톤을 나를 수 있는 트럭이 30톤의 물건을 다른 곳으로 옮길 때 1.5톤 트럭이 더 빨리 나를 수 있는 것과 같다. 윈도우즈 95와 98이 나왔을 때 전화 모뎀으로 인터넷에 접속했기 때문에 MTU 값을 전화 모뎀에 맞는 576바이트에 맞췄다. 하지만 초고속 인터넷 서비스는 모뎀보다 자료를 더 많이, 더 빨리 주고받을 수 있어 전화 모뎀에 맞춘 MTU 값은 초고속 인터넷에서 쓰기에 너무 작다. 초고속 인터넷 서비스에 맞는 MTU 값을 찾아 윈도우즈 네트워크 옵션을 업그레이드해주면 인터넷이 더 빨라진다. MTU 값은 커야 할까? 작아야 할까? 패킷 값의 크기는 큰 것이 좋을까? 작은 것이 좋을까? 초고속 인터넷 최적화에 대해 묻는 분들이 내놓는 질문이다. MTU 값의 크기에 따른 장단점을 알아보자. MTU 값을 크게 잡으면? MTU 값을 늘려 패킷을 크게 잡으면 인터넷 속도가 더 빨라질까? 그렇지 않다. 패킷은 인터넷으로 상대방에게 가면서 여러 개의 길잡이, 즉 라우터를 만난다. 라우터는 패킷과 패킷 안에 있는 송수신 정보를 보고 다른 네트워크 경로로 패킷을 보낸다. 패킷의 크기가 앞으로 지나갈 네트워크 경로가 감당할 수 없을 만큼 크면 통과할 수 있는 작은 크기로 나눠서 보낸다. 패킷이 너무 커 라우터를 지날 때마다 작은 조각으로 나뉘면 나뉘는 시간 때문에 패킷이 상대방에게 도달하는 시간이 더 걸린다. MTU 값을 줄이면? 패킷 크기를 무조건 줄이는 것도 좋지 않다. 패킷에는 송수신에 필요한 정보를 담은 부분이 있는데 실제로 보내는 순수한 데이터와는 관계없다. 따라서 데이터를 잘게 쪼갤수록 패킷이 많이 생기고, 각각의 패킷이 목적지에 닿으려면 송수신 정보가 늘어난다. 송수신 정보를 보내는 데 필요한 시간과 공간이 늘어나면 실제로 보내는 데이터의 양이 준다. 핑 테스트로 내게 꼭 맞는 MTU 값 찾기 MTU 값을 찾으려면 핑을 쓴다. 핑은 간단하면서도 유용한 네트워크 진단 유틸리티다. 핑을 쓰면 상대방 PC가 죽었는지 살았는지, 내가 보낸 응답에 대해 상대방 PC가 얼만큼 시간이 지나서 그 대답을 해주는지 알 수 있다. 핑을 잘 쓰면 MTU 값도 금방 찾는다. 내가 보낼 수 있는 가장 큰 패킷 크기를 정하고, 그 패킷이 쪼개져 보내지면 안된다는 옵션을 건다. 이렇게 패킷 옵션을 정하고 목적지로 보내면, 패킷을 받은 라우터는 내가 보낸 패킷이 너무 크다고 여겨 목적지로 패킷을 보내기 위해 작은 크기로 나누려고 한다. 하지만 보낸 쪽에서 패킷을 나누지 말라는 옵션을 붙어 보냈기 때문에, 라우터는 패킷을 나눠서 보내는 대신 패킷을 전달할 수 없다는 메시지를 보낸다. 패킷의 크기를 바꿔가며 핑 테스트를 하다 보면, 라우터가 쪼개지 않아도 목적지로 보낼 수 있는 패킷 크기를 구할 수 있다. 패킷을 쪼개서 보낼 필요가 없기 때문에 라우터에서 패킷을 쪼개느라 걸리는 시간을 아끼고, 최대한 많은 데이터를 패킷에 담을 수 있어 더 빨리 데이터를 목적지에 보낸다. 바로 이 값을 MTU 값으로 만드는 것이다. 핑을 이용해서 MTU 값을 구하자. 적당한 MTU 값을 가지면 라우터에서 패킷을 쪼개 보낼 필요가 없어 시간이 절약되고, 데이터를 많이 보낼 수 있는 넉넉한 패킷 크기를 가지기 때문에 인터넷 속도도 빠르다. 1. 시작→실행을 누르고 빈 칸에 cmd를 적고 확인을 누른다. 2. 명령 프롬프트 창이 열린다. ping -f -l 1400 [내가 쓰는 초고속 인터넷 업체 서버]를 적고 엔터를 누른다. 3. 결과에 reply from ....’이라는 답이 나오면 1,400에서 1씩 올리면서, packet needs to be fragmented but df set이 나오면 1,400에서 1씩 내리면서 핑 테스트를 계속한다. 4. packet needs to be fragmented but df set이라는 메시지가 나오지 않는 가장 큰 수를 얻으면 테스트를 멈춘다. 값을 메모지에 적는다. 필자는 1,464가 가장 큰 숫자였다. 5. 테스트가 끝나면 결과 값에 28을 더한다. 그 결과 값이 내 초고속 인터넷에 딱 맞는 MTU 값이다. 1,464에 28을 더한 1,492가 MTU 값이다. 왜 핑 테스트 결과에 28을 더할까? 핑 테스트에서 얻은 결과는 송수신에 필요한 정보를 담은 20바이트의 IP 헤더와 데이터 송수신에 생기는 문제를 해결하기 위해 쓰는 인터넷 제어 메시지 프로토콜(ICMP:internet control message protocol)를 위한 8바이트의 공간을 계산하지 않고 빼두었다. 이 28 바이트의 공간은 패킷이 제대로 목적지에 가기 위한 정보를 담은 것으로 패킷을 보낼때 반드시 필요하다. 따라서 핑 테스트에서 구한 값에 테스트에서 빠진 IP 헤더와 ICMP를 위한 28바이트의 공간을 더한 값을 MTU 값으로 계산한다. 네트워크 옵션 자료 계산하기 MTU 값을 구했으면 이제 이 MTU 값을 가지고 네트워크 옵션에 필요한 자료를 계산한다. 필요한 값은 MSS(maximum segment size)과 RWIN(TCP receive window) 값이다. MSS 값은 데이터 송수신에 이용한 정보를 뺀 데이터의 양을 말한다. MTU 값에서 40바이트를 뺀 값을 MSS 값으로 쓴다. 즉, MTU 값이 1,492라면 MSS 값은 40을 뺀 1,452다. RWIN은 자료를 받는 쪽의 PC가 만들어 놓은 버퍼 공간이다. 자료를 보내는 쪽은 버퍼의 크기만큼 미리 자료를 보낼 수 있다. 받은 데이터에 문제가 없다는 것을 자료를 보내는 쪽에 알려주는데, 이때 몇 개의 실제 데이터(MSS)를 받은 뒤에 제대로 받았다는 것을 알려줄지 결정하는 것이 RWIN 값이다. RWIN 값은 항상 MSS 값의 배수로 계산해서 RWIN 값과 보낸 실제 데이터 양이 딱 맞아 떨어지게 한다. 초고속 인터넷을 위한 RWIN 값은 18만에서 40만 사이에 있는 값을 쓰는 것이 좋다. 방금 구한 RWIN 값을 10진수에서 16진수로 바꾸자. 윈도우즈에 있는 계산기 프로그램을 쓰면 10진수를 16진수로 쉽게 바꾼다. 1. 시작→프로그램→보조 프로그램→계산기를 고르고, 메뉴에서 보기를 눌러 공학용을 고른다. 2. 왼쪽에서 Dec을 고르고, 방금 구한 10진수의 RWIN 값을 적자. 필자는 MSS 값의 256배를 더한 371,712를 적었다. 3. Hex를 고른다. 십진수 371,712가 16진수인 5AC00로 변했다. 16진수로 변한 RWIN 값을 적어둔다. 초고속 인터넷용 레지스트리 파일 만들고 깔기 윈도우즈 2000과 XP를 위한 초고속 인터넷용 레지스트리 파일을 만들자. 윈도우즈 레지스트리 에디터로 레지스트리에 직접 네트워크 옵션을 넣을 수 있다. 레지스트리 파일로 만들면 윈도우즈를 새로 깔 때 편하다. 만들어 놓은 레지스트리 파일을 두 번 누르면 바로 윈도우즈 레지스트리에 초고속 인터넷에 딱 맞춘 네트워크 옵션을 넣어줘 매번 레지스트리 에디터를 열고 일일히 값을 넣어주지 않아도 된다. 초고속 인터넷을 위한 나만의 레지스트리 파일을 만들자. 1. 바탕 화면에 커서를 대고 마우스 오른쪽 버튼을 눌러 메뉴에서 새로 만들기→텍스트 문서를 고른다. 2. 새로운 파일 이름을 정한다. 필자는 myreg.reg라고 적었다. 어떤 이름을 써도 되지만 파일 확장자는 반드시 reg여야 한다. 3. 만든 파일에 커서를 대고 마우스 오른쪽 버튼을 눌러 편집을 누른다. 4. 메모장이 뜨면 다음을 입력한다. TcpWindowsSize와 GlobalMaxTcpWindowSize에는 앞에서 구한 16진수로 된 RWIN 값을 적는다. 나머지 값은 대소문자의 구분은 반드시 지킨다. Windows Registry Editor Version 5.00 <엔터> <엔터> [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters] <엔터> "SackOpts"=dword:00000001 <엔터> "TcpWindowSize"=dword:0005ac00 <엔터> "Tcp1323Opts"=dword:00000001 <엔터> "DefaultTTL"=dword: 00000080<엔터> "EnablePMTUBHDetect"=dword:00000000 <엔터> "EnablePMTUDiscovery"=dword:00000001 <엔터> "GlobalMaxTcpWindowSize"=dword:0005ac00 <엔터> 5. 파일→저장을 누른다. 창 오른쪽에 X를 눌러 닫는다. 6. 방금 만든 파일을 마우스 왼쪽 버튼으로 두 번 누르면 레지스트리에 등록하겠냐고 묻는 창이 뜬다. 예를 누른다. 7. 레지스트리에 등록되었다는 메시지가 뜬다. 확인을 누른다. 초고속 인터넷 패치가 효과가 있는지 알아보자 패치하기 전에 인터넷 속도를 검사하고, 패치한 뒤 다시 한번 인터넷 속도를 검사한다. 벤치비에서 초고속 인터넷을 패치하기 전과 패치한 뒤 차이를 알아본다. 1. 초고속 인터넷 패치를 하기 전 벤치비에서 속도 테스트 한다. 다운로드는 6.004Mbps, 업로드는 641.9Kbps가 나왔다. 2. 초고속 인터넷 패치를 하고 다시 벤치비에서 속도 테스트를 했다. 다운로드는 6.872Mbps로 패치하기 전보다 올라갔고, 업로드는 556.8kbps가 나와 패치하기 전보다 떨어졌다 ------------------------------------------------ 시스코 라우터 1700 fa0에서 같은 장비의 fa0으로 18024바이트로 핑 테스트를 했습니다. 그런데 MTU 이상의 패킷으로 핑이 나가는 이유를 모르겠습니다. 자동으로 프래그먼테이션(Fragmentation)을 하는 것인지 어떤것인지 궁금합니다. A. 라우터에서 MTU 이상의 패킷이 나갈 경우 자동으로 플래그먼트하는 것입니다. 그래서 라우터에서 MTU 이상의 패킷을 보낸 후 스니퍼로 캡쳐를 해 봤습니다. 라우터에서 확장 핑 옵션으로 2000바이트로 테스트했습니다. 다음 화면을 보면 1514와 534로 자동으로 나뉘어 패킷이 오고 가는 것을 볼 수 있습니다. 화면에서는 'more fragments' 부분의 값이 1로 지정돼 분열된다는 것을 알 수 있습니다. 참고하시길 바랍니다.     -----------------------------------------------------      Path MTU Discovery 와 ICMP 필터링에 대해                                    정리: 홍석범(antihong@tt.co.kr) 이 문서에서는 path MTU discovery 와 ICMP 필터링과의 상관 관계에 대해 알아보도록 한다. 먼저 관련된 용어의 정의부터 알아보도록 하자. # MTU  MTU 란 Maximum Transmission Unit 의 약자로서 하나의 프레임이나 패킷이 한번에 전송이 될 때 이더넷등을 통과할 수 있는 데이터의 크기이다. 이 값은 아래와 같이 어떤 프로토콜인가에 따라 다르다.   Hyperchannel            65535   16Mbit/s token ring     17914   Token Bus               8166   Ethernet                1500   X.25                    576 # Path MTU 현재 두 호스트간 경로에서 가장 작은 MTU 값을 말한다. 이 값은 라우팅 경로가 매번 일정하지 않고 수시로 바뀌므로  이 값도 라우팅 경로에 따라 수시로 변경될 수 있다. 그리고 같은 호스트 사이라 하더라도 두 호스트간의 트래픽 종류에 따라(즉 X.25인지 이더넷인지등에 따라) 값이 달라진다. # Fragmentation 패킷이 너무 커서 하나의 단일한 단위로 이더넷등을 통과할 수 없을 경우 즉 패킷의 사이즈가 라우터의 MTU 값보다 큰 경우 라우터에서는 패킷을 Fragmentation(조각화)하여 몇 개의 부분으로 나누어 수신자에게 패킷을 포워딩하여 전달하게 되고 수신자는 이 조각을 모두 수신한 후 재조립하게 된다. 그러나 Fragmentation 을 하게 되면 다음과 같은 문제가 발생하게 된다. (1) 패킷의 한 조각이 drop 되면 나머지 모든 패킷을 재전송하여야 하며      결국 많은 오버헤드를 유발하게 된다. (2) 라우터에서 패킷을 조각화하는 과정에서 많은 오버헤드가 발생하게 된다. (3) 어떤 방화벽에서는 아예 조각화한 패킷을 drop 해 버린다. # DF(Don't Fragment) 패킷 발송시 패킷 헤더에 DF 비트를 설정할 경우 설사 라우터의 MTU 값이 작아  Fragment 를 하여야 할 지라도 조각화하지 말라는 설정이다. 이 패킷을 받은 라우터에서는 이 패킷을  drop 하고 "can't fragment" 라는 ICMP 에러 메시지를 발송자에게 전송한다. # Can't Fragment 에러 이 에러는 라우터에서 MTU 보다 큰 패킷이 왔지만 DF 비트가 설정되어 Fragment 를 할 수 없어 패킷의 발송자에게 발송하는 ICMP 에러 메시지이다. 이 메시지는 "패킷의 사이즈를 MTU 보다 줄여서 다시 발송하라" 는 의미가 있으며 이 패킷에는 MTU 값도 함께 명기된다. 이 에러는 오직 DF 비트가 설정되어 있을 경우에만 발생하며 DF 비트가 설정되어 있지 않으면 라우터는 단지 이 패킷을 조각화한후 다음 수신자 경로로 포워딩하게 된다. # Path MTU Discovery(PMTU-D) 앞에서 이야기한 것처럼 MTU 값은 다양하다는 것을 알았다. 또한 Fragmentation 은 Performance의 관점에서 그리 좋지 않은 것이라는 것도 알았다. 그렇다면 이에 대한 해결책은 무엇인가? 바로 Path MTU Discovery 이다. 이는 분절화는 피하면서 가장 큰 사이즈의 패킷을 발송하는 것이다. 이는 원격지 시스템이 알려준 MTU 나 MSS(Maximun Segment Size) 값보다 약간 작은 최대 사이즈로 설정하여 보내면 되는 것이다. 물론 이 패킷에는 DF 비트가 설정되어 있을 것이다. 만약 패킷이 MTU 값보다 커서 패킷을 발송할 수 없으면 ICMP 에러 메시지를 전송하는데 이 패킷에는 MTU 값이 지정되어 있어 이 메시지를 받은 송신자는 이 MTU로 재조합하여 다시 발송하게 된다. ICMP 필터링과 PMTU-D 와의 관계 만약 송신자쪽의 라우터나 방화벽에서 inbound 되는 ICMP 패킷을 필터링한다면 어떻게 될까? 이러한 경우 송신자쪽에서 DF 비트를 설정한 채 MTU 값을 초과하는 패킷을 발송하더라도 수신자쪽의 라우터에서 패킷이 너무 커서 전송할 수 없다는 "Can't Fragment" ICMP 에러 메시지를 받을 수 없게 되어 계속적으로 큰 사이즈의 패킷을 보내게 되고 수신자는 계속 필터링하게 되어 네트워크의 성능이 크게 떨어지게 된다. 따라서 MTU 보다 작은 데이터는 통과하게 되고 큰 데이터는 drop 되어 전달되지 않는 현상이 발생하게 된다. 이러한 경우 몇가지 해결방안이 있다. (1) 필터링 정책을 수정한다. 이 문제는 ICMP 에 대한 충분한 이해없이 ICMP 를 필터링한데에 있다. ICMP 에서는 TCP 나 UDP처럼 포트라는 개념이 없는대신 "ICMP 메시지타입" 이라는 것이 있어 이를 기준으로 하여 필터링을 하거나 허용할 수 있는데, 만약 inbound 되는 ICMP 를 차단하였다면 ICMP type 3번중 code 4번인 "Fragmentation Needed and Don't fragment" 를 허용하면 된다. (http://www.iana.org/assignments/icmp-parameters 를 참고하기 바란다. ->밑에 첨부) 만약 이 필터링이 자기 자신이 아닌 목적지 사이에 어딘가에 있다면 이 패킷을 필터링한 네트워크 담당자에게 이 문제를 확인하여 해결해 줄것을 요청하여야 한다. (2) MTU값을 줄인다. MTU 값을 줄여 발송하는 시스템이 Path MTU 일 경우 애초 패킷 발송시에 가장 작은 MTU 값으로 발송하게 되므로 이 문제가 발생하지 않게 될 것이다. 그러나 이 방법은 꼭 필요하지 않으면 하지 않는 것이 좋다. (3) PMTU-D 를 하지 않는다. 이도 한가지 방법이 될 수는 있지만 꼭 필요하지 않으면 하지 않는 것이 좋다. Reference http://www.ietf.org/rfc/rfc1191.txt?number=1191 http://www.worldgate.com/~marcs/mtu/ ======================================================================================== ICMP TYPE NUMBERS (last updated 2003-11-06) The Internet Control Message Protocol (ICMP) has many messages that are identified by a "type" field. Type Name Reference ---- ------------------------- ---------   0 Echo Reply [RFC792]   1 Unassigned     [JBP]   2 Unassigned     [JBP]   3 Destination Unreachable [RFC792]   4 Source Quench [RFC792]   5 Redirect [RFC792]   6 Alternate Host Address     [JBP]   7 Unassigned     [JBP]   8 Echo [RFC792]   9 Router Advertisement [RFC1256] 10 Router Solicitation [RFC1256] 11 Time Exceeded [RFC792] 12 Parameter Problem [RFC792] 13 Timestamp [RFC792] 14 Timestamp Reply [RFC792] 15 Information Request [RFC792] 16 Information Reply [RFC792] 17 Address Mask Request                     [RFC950] 18 Address Mask Reply [RFC950] 19 Reserved (for Security)    [Solo] 20-29 Reserved (for Robustness Experiment)     [ZSu] 30 Traceroute [RFC1393] 31 Datagram Conversion Error [RFC1475] 32     Mobile Host Redirect              [David Johnson] 33     IPv6 Where-Are-You                 [Bill Simpson] 34     IPv6 I-Am-Here                     [Bill Simpson] 35     Mobile Registration Request        [Bill Simpson] 36     Mobile Registration Reply          [Bill Simpson] 37     Domain Name Request                     [RFC1788] 38     Domain Name Reply                       [RFC1788] 39     SKIP                                    [Markson] 40     Photuris                                [RFC2521] 41-255 Reserved     [JBP] Many of these ICMP types have a "code" field.  Here we list the types again with their assigned code fields. Type    Name                                    Reference ----    -------------------------               ---------   0     Echo Reply                               [RFC792]         Codes             0  No Code   1     Unassigned                                  [JBP]   2     Unassigned                                  [JBP]   3     Destination Unreachable                  [RFC792] Codes     0  Net Unreachable     1  Host Unreachable             2  Protocol Unreachable             3  Port Unreachable             4  Fragmentation Needed and Don't Fragment was Set             5  Source Route Failed             6  Destination Network Unknown             7  Destination Host Unknown             8  Source Host Isolated             9  Communication with Destination Network is                Administratively Prohibited            10  Communication with Destination Host is                Administratively Prohibited            11  Destination Network Unreachable for Type of Service            12  Destination Host Unreachable for Type of Service            13  Communication Administratively Prohibited      [RFC1812]            14  Host Precedence Violation                      [RFC1812]            15  Precedence cutoff in effect                    [RFC1812]   4     Source Quench                            [RFC792]         Codes             0  No Code   5     Redirect                                 [RFC792]         Codes             0  Redirect Datagram for the Network (or subnet)             1  Redirect Datagram for the Host             2  Redirect Datagram for the Type of Service and Network             3  Redirect Datagram for the Type of Service and Host   6     Alternate Host Address                      [JBP]         Codes             0  Alternate Address for Host   7     Unassigned                                  [JBP]   8     Echo                                     [RFC792]         Codes             0  No Code   9     Router Advertisement                    [RFC1256]         Codes             0  Normal router advertisement                 16  Does not route common traffic    [RFC2002] 10     Router Selection                        [RFC1256]         Codes             0  No Code 11     Time Exceeded                            [RFC792]         Codes             0  Time to Live exceeded in Transit             1  Fragment Reassembly Time Exceeded 12     Parameter Problem                        [RFC792]         Codes             0  Pointer indicates the error             1  Missing a Required Option        [RFC1108]             2  Bad Length 13     Timestamp                                [RFC792]         Codes             0  No Code 14     Timestamp Reply                          [RFC792]         Codes             0  No Code 15     Information Request                      [RFC792]         Codes             0  No Code 16     Information Reply                        [RFC792]         Codes             0  No Code 17     Address Mask Request                     [RFC950]         Codes             0  No Code 18     Address Mask Reply                       [RFC950]         Codes             0  No Code 19     Reserved (for Security)                    [Solo] 20-29  Reserved (for Robustness Experiment)        [ZSu] 30     Traceroute                              [RFC1393] 31     Datagram Conversion Error               [RFC1475] 32     Mobile Host Redirect              [David Johnson] 33     IPv6 Where-Are-You                 [Bill Simpson] 34     IPv6 I-Am-Here                     [Bill Simpson] 35     Mobile Registration Request        [Bill Simpson] 36     Mobile Registration Reply          [Bill Simpson] 39     SKIP                                    [Markson] 40     Photuris                                [RFC2521] Codes             0 = Bad SPI             1 = Authentication Failed             2 = Decompression Failed             3 = Decryption Failed             4 = Need Authentication             5 = Need Authorization REFERENCES ---------- [RFC792] Postel, J., "Internet Control Message Protocol", STD 5,          RFC 792, USC/Information Sciences Institute, September 1981. [RFC950] Mogul, J., and J. Postel, "Internet Standard Subnetting          Procedure", STD 5, RFC 950, Stanford, USC/Information          Sciences Institute, August 1985.  [RFC1108] Kent, S., "U.S. Department of Defense Security Options for           the Internet Protocol", RFC 1108, November 1991. [RFC1256] Deering, S., Editor, "ICMP Router Discovery Messages", RFC           1256, Xerox PARC, September 1991. [RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393,           Xylogics, Inc., January 1993. [RFC1475] Ullmann, R., "TP/IX: The Next Internet", RFC 1475, Process           Software Corporation, June 1993. [RFC1788] W. Simpson, "ICMP Domain Name Messages", RFC 1788, April 1995. [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC           1812, Cisco Systems, June 1995. [RFC2002] C. Perkins, Editor, "IP Mobility Support", RFC 2002,           October 1996. [RFC2521] P. Karn and W. Simpson, "ICMP Security Failures Messages",           RFC 2521, March 1999. PEOPLE ------ [JBP] Jon Postel, <postel@isi.edu>, September 1995. [David Johnson] [Markson] Tom Markson, <markson@osmosys.incog.com>, September 1995. [Simpson]  Bill Simpson, <Bill.Simpson@um.cc.umich.edu>, October 1995. [Solo] [ZSu] Zaw-Sing Su <ZSu@TSCA.ISTC.SRI.COM> []