RFC1771 A Border Gateway Protocol 4 – 邊界網關協議版本4 Read more

RFC1771 A Border Gateway Protocol 4 – 邊界網關協議版本4

Last updated:29th April, 2016, 7:34 PM本備忘錄的狀態 本文檔講述了一種Internet社區的Internet標準跟蹤協定,它需要進一步進行討論和建議以得到改進。請參考最新版的“Internet正式協議標準” (STD1)來獲得本協定的標準化程度和狀態。本備忘錄的發佈不受任何限制。 摘要 本文檔,以及隨同文檔,“邊檢閘道協議在互聯網中的應用”,定義了互聯網的自治系統間路由式通訊協定。 目錄 致謝 3 介紹 3 操作總結 4 3.1 路由:通告和存儲      5 3.2 路由信息庫   5 消息格式 5 4.1 消息頭格式   6 4.2 OPEN消息格式 6 4.3 UPDATE消息格式      8 4.4 KEEPALIVE消息格式   13 4.5 NOTIFICATION消息格式        13 路徑屬性 15 5.1 路徑屬性使用  16 5.1.1 ORIGIN   16 5.1.2 AS-PATH  16 5.1.3 NEXT-HOP 16 5.1.4 […]

RFC1769 Simple Network Time Protocol – 簡單網路時間協議 Read more

RFC1769 Simple Network Time Protocol – 簡單網路時間協議

Last updated:28th April, 2016, 8:07 PM本備忘錄的狀況: 本備忘錄為Internet community提供了資訊,但不規定任何一種類型的 Internet 標準。 本備忘錄的分發沒有限制。 概要 本備忘錄描述簡單網路時間協定(SNTP),這是網路時間協定(NTP) 的一個改寫本,NTP協議 適用於同步網際網路上的電腦時鐘。當不須要實現RFC 1305 所描述的NTP完全功能的情況下,可以使用SNTP。它能用單播方式(點對點)和廣播方式(點對多點)操作。它也能在IP 多播方式下操作(可提供這種服務的地方)。SNTP與當前及以前的NTP版本並沒有大的不同。但它是更簡單,是一個無狀態的遠端程式呼叫(RPC),其準確和可靠性相似於UDP/TIME 協議在RFC868描述中所預期的。 本備忘錄淘汰相同的標題的RFC 1361。它的目的是解釋用廣播方式操作的協定模式,提供某些地方的進一步說明並且改正一些印刷上的錯誤。在NTP版本3 RFC 1305中說明的工作機理對SNTP的實現不是完全需要的。本備忘錄的分發沒有限制。 目錄 介紹 2 工作模式與位元址分配 2 NTP時間戳記格式 3 NTP 報文格式 4 SNTP 用戶端操作 6 SNTP 伺服器操作 7 參考資料 8 安全考慮 9 作者的地址 9 介紹 RFC 1305 [MIL92] 指定網路時間協定(NTP)來同步網際網路上的電腦時鐘。它提供了全面訪問國家時間和頻率傳播服務的機制,組織時間同步子網並且為參加子網每一個地方時鐘調整時間。 在今天的網際網路的大多數地方, NTP 提供了1-50 ms 的精確度,精確度的大小取決於同步源和網路路徑等特性。 […]

RFC1723 RIP Version 2 Carrying Additional Information – 路由信息協議(版本2) Read more

RFC1723 RIP Version 2 Carrying Additional Information – 路由信息協議(版本2)

Last updated:26th April, 2016, 7:36 PM本文檔的狀態 本文檔詳細說明了一種Internet標準的循路協議以及進一步的請求討論和建議。 請參考最新版的“Internet正式協議標準(STD1)”來獲得本協定的標準化程度和狀態。 本文檔的發佈不受任何限制。 概要 本文檔詳細說明了正如定義在[1,2]中的路由資訊通訊協定的擴展,擴充了在RIP資訊中攜帶有用資訊的數量,增加了安全措施。 在本文檔的舊文檔RFC1388中,描述了對“路由資訊通訊協定”STD34(RFC1058)的更新信息。 RIP-2 協議分析參考文檔RFC1721[4] IP-2 適用性陳述參考文檔RFC1722[5] RIP-2 管理系統庫的描述參考文檔RFC1724[3] RFC1389是其舊文檔 致謝 感謝ITTF ripv2 工作組對RIP-2協議改進提供説明 目錄 1、源由 . . . . . . . . . . . . . . . . . . …………….. . . . . . . 2 2. 現行的RIP協定 . . […]

RFC1661 The Point-to-Point Protocol (PPP) – PPP協議 Read more

RFC1661 The Point-to-Point Protocol (PPP) – PPP協議

Last updated:24th April, 2016, 6:33 PM摘要 PPP為基於點對點連接的多協定自定址資料包的傳輸提供了一個標準方法。PPP包含以下三個成分: 1. 壓縮多協定自定址資料包的方法。 2. 用於建立、設定和測試資料連結連接的LCP。 3. 一族用於建立、設定不同網路層協定的NCP。 本文檔定義了PPP的組織和方法,以及PPP封裝,與之一起定義的還有:擴展選項協商機制,他使得(人們)可以就豐富的設定參數進行磋商,同時還提供額外的管理功能。PPP鏈路控制協議(LCP)九是用這種機制描述的。 目錄 1 介紹 3 1-1 要求說明書 4 1-2 術語 4 2 PPP封裝 5 3 PPP鏈路操作 6 3-1 概述 6 3-2 階段劃分框圖 6 3-3 鏈路死亡(物理連接不存在) 6 3-4 鏈路建立階段 7 3-5 認證階段 7 3-6 網路層協定階段 7 3-7 鏈路終止階段 8 4 自動機協商選項 8 4-1 […]

RFC1618 PPP over ISDN – ISDN上的PPP(點對點)協議 Read more

RFC1618 PPP over ISDN – ISDN上的PPP(點對點)協議

Last updated:21st April, 2016, 9:42 PM本備忘錄的狀態 本文檔詳細說明了Internet團體的一個Internet標準協定, 並需要經過討論建議加以改進。關於這個協定的標準化狀態,請參考Internet官方協議標準(STD1)。 概要 點對點通訊協定(PPP)[1] 為多協議的報文在點對點的鏈路上的傳輸提供了一種標準的 方法。此文檔描述了PPP在ISDN(綜合數位業務網)交換電路上的使用。 這個文檔是IETF點對點通訊協定工作組的成果。 任何建議及注解可以發送到郵寄清單ietf-ppp@merit.edu。 適用性: 此規範用於需要使用在ISDN點對點鏈路上進行PPP封裝的實現。PPP不針對多點或多重訪問環境而設計。 “顯然,ISDN決不可能是單一的和全球統一的。” 此文檔的目的是描述一些從現今各種廣泛的應用中選擇出的普遍的實現方法, 以利於提高協同性。 目錄 1 介紹 2 2 實體層要求 2 3 框架格式 3 4 帶外信號 4 5 配置細節 4 6 安全上的考慮 4 7 參考 4 8 致謝 5 9 聯繫方式 5 1 介紹 PPP(點對點通訊協定)是作為一種點到點的鏈路上的通信的標準方法而設計。最初應用於短的本地線路, 租借線路和使用數據機的普通電話線路。隨著新的報文服務和更高速的線路的引進,PPP在這些環境同樣能容易地實施。 此規範主要涉及到PPP封裝在ISDN線路上的使用。 由於ISDN B通道從定義上是點對點的電路, 所以PPP很適合在這些鏈路上使用。 […]

RFC1413 Identification Protocol – 鑑定協議 Read more

RFC1413 Identification Protocol – 鑑定協議

Last updated:20th April, 2016, 7:55 PM此備忘錄的狀態: 本標準為Internet網詳細說明了架構委員會標準軌跡協議,以及需求大家討論和建議來進一步提高.敬請關注最新版本標準化陳述和此協定的情況的檔”IAB Official Protocol Standards”.本備忘錄的發行無任何限制. 目錄 1、介紹 1 2、概述 2 3、約束條件 2 4、詢問/回應格式 2 5、回應類型 2 6、安全性考慮 5 7、致謝 6 參考資料 6 作者地址 6 1、介紹 本鑒定協定提供了一種測定使用者的特殊的TCP連接身份的手段. 提供了TCP埠對,它返回的字串識別出連接在伺服器系統上的使用者. 此協定以前叫”the Authentication Server Protocol”(伺服器鑒定協議).改名是為了更好的反映出其功能,本檔是網際網路工程任務組的TCP身份協議工作組(TCP Identity Protocol Working Group )的產品, 2、概述 這是建立在TCP申請的連接,伺服器在TCP的113(十進位)埠監測TCP連接,一旦連接建立,伺服器在一線路上讀取重要的資料,假如存在,系統重要連接可靠性使用者識別項將被發送作為回答.然後伺服器可以斷開連接或者讀取並回答更多的詢問. 在推薦60—180秒內如沒有接收到任何資訊,那麼伺服器將斷開連接.用戶可以隨時斷開連接,但是,由於網路的延遲,使用者必須等待至少30秒,他(她)的訪問方被放棄並斷開連接. 3、約束條件 詢問僅僅限定在指定的連接.詢問包括局部和國外埠對,他們用來詳細說明連接是來自局部或外國的詢問連接.這說明關於A與B之間的連接一個用戶在A地只能詢問B地的伺服器. 4、詢問/回應格式 伺服器只接受如下方式的請求: <port—on—server>,<port—on—client><port—on—server>的內容是TCP埠目標,而<port—on—client>是TCP埠來源. N.B—如果客戶主機A在主機B申請局部連接為23, 6191的服務,客戶必須訪問23, 6191—也就是連接在主機B是如何被指定的. 例: 6191, 23 […]

RFC1388 RIP Version 2 – RIP協議版本2 Read more

RFC1388 RIP Version 2 – RIP協議版本2

Last updated:19th April, 2016, 7:31 PM摘要 這份文檔詳細說明了關於路由資訊通訊協定(RIP-1,見RFC1058)的擴展,在RIP包中增加了一些有用的路由資訊以及一種安全措施。還有一份相關文檔描述了RIP-2的SNMP管理系統庫。 致謝: 我要感謝以下幾位為這份文檔作出了貢獻:Fred Baker,Noel Chiappaand Vince Fuller。這份文檔是Internet工程任務組的RIP-2工作組的工作成果。 目錄: 1. 為RIP的辯護 2. 現在的RIP 3. 協定擴展 3.1 驗證機制 3.2 選擇域路由 3.3 路由標記 3.4 子網路遮罩 3.5 下一跳 3.6 多點廣播 4. 相容性 4.1 相容的轉換 4.2 驗證機制 4.3 多重度量制式 4.4 無位址連接 附錄 A 參考文獻 安全注意事項 作者地址 1. 為RIP的辯護 隨著OSPF與IS-IS的出現,許多人都相信RIP已經過時了。 事實上,儘管新的IGP路由式通訊協定的確比RIP優越得多,但RIP也確有它自己得一些優點。首先,在一個小型網路中,RIP對於使用頻寬以及網路的配置和管理方面的要求是很少的,與新的IGP相比,RIP非常容易實現。 此外,現在RIP還在大量使用,這是OSPF與IS-IS所不能比的。而且,看起來這種狀況還將持續一些年。 既然RIP在許多領域和一定時期內仍具有使用價值,那麼就有理由增加RIP的有效性,這是毫無疑問的,因為對已有技術進行改造所獲收益比起徹底更新要現實得多。 2.現在的RIP 現在的RIP包中只是包含了路由器為包在網路上選路所需要的最小限度的路由資訊。由於歷史原因,在現在的RIP包中還有大量的未被使用的空間。 […]

RFC1332 The PPP Internet Protocol Control Protocol – 端對端協議網間協議控制協議 Read more

RFC1332 The PPP Internet Protocol Control Protocol – 端對端協議網間協議控制協議

Last updated:16th April, 2016, 6:41 PM摘要 PPP協定(端對端協定)[ 1 ]提供在點對點鏈路上面壓縮網路層協定資訊的標準的方法。同樣,PPP協定定義可擴展的鏈路控制協定,和為了建立和配置不同的網路層協定的網路控制協定(NCP)族。 本文檔定義了為了在PPP協定上面建立和配置網間協定[ 2 ]的NCP,以及協商和使用PPP協議上Van Jacobson TCP/IP報頭壓縮[ 3 ]的方法。 本RFC是國際網工作交流協會的串列點協議工作(IETF)小組的成果。 目錄 1.介紹 2 2.端對端協定網路控制協定(NCP)為IP 2 2.1 發送IP資料包 3 3.IPCP配置可選項 3 3.1 IP-地址(IP-Addresses) 3 3.2 IP-壓縮協議 4 3.3 IP-地址(IP-Address) 4 4.VAN JACOBSON TCP/IP報頭壓縮 5 4.1 配置可選項格式 5 附錄A.IPCP推薦的可選項 6 安全考慮 6 參考 6 1.介紹 PPP協定有3個主要的部分: 1.串列的鏈路上壓縮資料包的方法。 2.完成鏈路建立,配置的資料連結控制協定(LCP)。 3.為網路層協定族配置不同的網路層協定的網路控制協定(NCP)。 為了在點到點鏈路上面建立通信,每個PPP協定鏈路的端都為了配置和試驗必須首先發LCP包。在鏈路經過LCP選擇和建立之後,PPP必須發送NCP包選擇和配置一個或一個以上的網路層協定。如果每個被選中的網路層協定都被配置,來自每個網路層協定的資料包就能在鏈路上面被發送。 […]

RFC1298 SNMP over IPX – 基於IPX協議的SNMP Read more

RFC1298 SNMP over IPX – 基於IPX協議的SNMP

Last updated:15th April, 2016, 7:35 PM本備忘錄的狀態 本文檔講述了一種Internet社區的Internet標準跟蹤協定,它需要進一步進行討論和建議以得到改進。請參考最新版的“Internet正式協議標準” (STD1)來獲得本協定的標準化程度和狀態。本備忘錄的發佈不受任何限制。 版權聲明 Copyright (C) The Internet Society (2001). 摘要 本文檔建議了簡單網路管理協定SNMP包如何在網際包切換式通訊協定IPX封裝的傳輸機制。 1. 介紹 SNMP協議已經被指定為Internet上使用的正式的網路管理協定。它已經在Internet上和非Internet網路中被開發者廣泛接受和使用。由此已產生了相關的協議和平臺。 本節定位於在IPX上使用SNMP,其主要因為Novell NetWare的流行而廣泛普及。 大略的等同UDP的功能,IPX也提供了基於不同物理介質和協定上的不需連線的、非確認的資料包服務。 儘管NetWare協議族已經做了修改,IPX因其來源於Xerox的網際資料包協議IDP,其通訊端位址空間的授權仍由Novell管理。 在UDP上使用SNMP是目前Internet最普通的方式。本描述應最適合於那些UDP傳輸服務不可用的環境。SNMP執行者應該意識到下層的傳輸方式會對Internet管理能力的互通性和普遍性產生重要影響。選擇適當SNMP傳輸方式的描述在[5]。 2. 詳細描述 SNMP通常會把IPX包頭的包類型域Packet Tyep Field的值設為4(也就是包交換包Packet Exchange Packet)。 2.1. 通訊端指定 SNMP實體在埠號36879接收GetRequest-PDU, GetNextRequest-PDU, and SetRequest-PDU消息(目標通訊端設為十六進位的值900F),在埠36880接收Trap-PDU 消息(目標通訊端設為十六進位的值9010F)。 GetResponse-PDU 消息的IPX位址和通訊端是根據相應的GetRequest-PDU、GetNextRequest-PDU、or SetRequest-PDU消息的發起點確定的。 2.2. 最大資料包長度 儘管SNMP沒有統一要求執行接收超過484位元組的消息,建議支援執行最大SNMP消息的長度為546位元組(IPX下允許的最大尺寸)。此外這個限制也是擔保的資料通過IPX路由器不分段的最大包長度。執行者如果知道最大值,應該選擇使用較大的資料包。這個最大值是由中間的路由器或者中間的鏈路層協議決定的。 2.3. Trap-PDU的agent-addr 域 由SNMP代理所發出的Trap-PDU其中的agent-addr 域應當包含IP位址0.0.0.0。 SNMP管理器可能會通過查詢傳輸層來確定陷阱來源。 2.4. IPX傳輸位址的表示 有時有必要在MIB中表示IPX傳輸服務位址。比如說SNMP MIB中使用OBJECT […]

RFC1288 The Finger User Information Protocol – Finger用戶信息協議 Read more

RFC1288 The Finger User Information Protocol – Finger用戶信息協議

Last updated:14th April, 2016, 7:36 PM備忘錄狀態 這個備忘錄定義了使用者資訊切換式通訊協定.這個RFC詳細說明了網際網路中的IAB標準追蹤協議,和討論要求以及提高的建議.請查閱當前版本的”IAB正式協定標準”來確立協定規定和狀態的標準化.該備忘錄的發行沒有限制. 摘要 這個備忘錄描述了Finger使用者資訊協定.這是一個為遠端使用者資訊程式提供介面的簡單協議. 以前面描述最初Finger協議的RFC742為基礎,這個備忘錄盡力闡明Finger連接兩端的期望通訊.它還盡力不使前面許多存在的執行失效或增加對前面最初協議定義的不必要限制. 這個版本更正和闡明了RFC1196. 目錄 1. 簡介 ……………………………………. 2 1.1. 目的 ……………………………………….. 2 1.2. 歷史 ………………………………………. 3 1.3. 要求 ………………………………….. 3 1.4. 更新 ………………………………………. 3 2. 協定的使用 ……………………………… 4 2.1. 事物流 ………………………………… 4 2.2. 資料格式 …………………………………… 4 2.3. 查詢指定 …………………………… 4 2.4. RUIP {Q2} 表現 …………………………….. 5 2.5. […]