TCPIP詳解 卷1協議 六 DHCP和自動配置

6.1——DHCP和自動配置

為了使用 TCP/IP 協議族,每臺主機和路由器需要一定的配置信息。基本上采用3種方法:手工獲得信息;通過一個系統獲得使用的網絡服務;使用某種算法自動確定。

擁有一個IP 地址和子網掩碼,以及 DNS 服務器和路由器的IP 地址,這是一個系統能夠在Internet上運行并提供常用服務的“基本要素”。

除了上述基本要素之外,主機或路由器的配置信息可能還需要很多其他要素,這取決于它使用或提供的服務類型。它們可能包括家鄉代理、組播路由器、VPN網關和會話發起協議(SIP)/VoIP 網關的位置。

6.2——動態主機配置協議(DHCP)

DHCP是一種流行的客戶機/服務器協議,它用于為主機(有時也為路由器)指定配置信息。通常使用 DHCP 獲得 IP 地址、子網掩碼、路由器的IP 地址、DNS 服務器的 IP 地址。DHCP 的最初設想是供 IPv4 使用,IPv6 使用的 DHCP 版本是DHCPv6,IPv6還支持自己的自動程序來確定配置信息。在一種混合配置模式中,IPv6 自動配置和 DHCPv6 可結合使用。

DHCP 的設計基于一種早期協議——稱為Internet引導程序協議(BOOTP),它目前已過時。BOOTP為客戶提供有限的配置信息,并且沒有提供一種機制來支持改變已提供的信息。DHCP 使用租用的概念來擴展 BOOTP模型,并且可提供主機操作所需的所有信息。租用允許客戶機使用一個商定的時間來配置信息。客戶機可向DHCP 服務器請求續訂租約,并繼續操作。在這個意義上,BOOTP 和 DHCP 是向后兼容的,純 BOOTP 客戶端可使用 DHCP 服務器,DHCP 客戶端也可使用純 BOOTP 服務器。因此,BOOTP和DHCP同樣使用UDP/IP。客戶機使用端口68,服務器使用端口67。

DHCP 由兩個主要部分組成:

  • 地址管理:用于IP 地址的動態分配,并為客戶機提供地址租用。
  • 配置數據交付:包括DHCP協議的消息格式和狀態機。

DHCP服務器可配置為提供三種地址分配:

  • 自動分配:客戶機從服務器配置的地址池(通常為一個預定義的范圍)中獲得一個不可撤銷的IP 。
  • 動態分配:最常用方法。客戶機從服務器配置的地址池(通常為一個預定義的范圍)中獲得一個可撤銷的IP 地址。
  • 手動分配:DHCP 協議用于傳輸地址,但地址對于請求的客戶機是不變的(即它不是由服務器維護的可分配池的一部分)。DHCP 的作用如同 BOOTP。

三者之間的差異是地址分配是否基于客戶機的身份,以及該地址是否可撤銷或變更。

6.2.1 地址池和租用

在動態分配中,DHCP 客戶機請求分配一個IP 地址。服務器從可用的地址池中選擇一個地址作為響應。在通常情況下,這個池是專門為 DHCP 用途而分配的一個連續的IP 地址范圍。分配給客戶機的地址只在一段特定時間內有效,這段時間稱為租用期。客戶機可使用這個地址直到租用期到期,客戶機提出延長租用期的要求。

租用期是 DHCP 服務器的一個重要配置參數。確定租用期的最佳數值需要對預期客戶數、地址池大小和地址穩定性等因素加以權衡。較長的租用期通常會較快耗盡可用的地址池,但能提供更穩定的地址和減小網絡開銷(因為續租請求較少)。較短的租用期可為其他客戶提供可用性更高的地址池,隨之而來的是穩定性減小和網絡流量負荷增大。常見的默認值包括12 24小時,取決于使用的DHCP服務器。例如,微軟建議較小的網絡采用8天,較大的網絡采用1624天。客戶機在租用期過半時開始嘗試續訂租約。

當發送 DHCP請求時,客戶機需要向服務器提供信息。這些信息可包括客戶機名稱、請求的租用期、已使用或最后使用過的地址副本和其他參數。當服務器接收到這個請求時,它可利用客戶機提供的信息(包括 MAC 地址請求),結合其他從外部獲得的信息(例如一天的時間、接收請求的接口),決定在響應中提供的地址和配置信息。當服務器向客戶機提供租用期時,服務器將租用信息保存在持久性存儲器中,通常是非易失性內存或磁盤中。如果DHCP 服務器重新啟動并且運行良好,租約將保持完好。

6.2.2 DHCP和BOOTP消息格式

DHCP擴展了BOOTP

image-20250413184604079

  • Op(操作):標識消息是請求(1)或應答(2)。

  • HW類型:基于ARP使用的值,常見的是1(以太網)。

  • HW長度:硬件(MAC)地址的長度,類似以太網的網絡,該值通常為6。

  • 跳步數:用于保存消息傳輸過程中的中繼次數。消息發送方將該值設置為0,并在每次中繼時遞增。

  • 事務ID:由客戶機選擇的一個(隨機)數,服務器需要將它復制到響應中。它用于將應答與請求匹配。

  • 秒數:由客戶機設置,它是第一次嘗試申請或重新申請地址經過的秒數。

  • 標志:當前只包含一個經過定義的位,稱為廣播標志。客戶機可能在請求中設置該位,表示它們不能或不愿處理單播 IP 數據報,但可處理廣播數據報(例如,由于它們沒有IP 地址)。通過設置該位通知服務器和中繼代理,廣播地址可用于響應中。

  • 客戶機IP地址:請求者的 IP 地址(如果已知),否則為0。

  • “你的”IP地址:由服務器填寫,以便向請求者提供服務器地址。

  • 下一個服務器IP地址:由服務器填寫,以便向請求者提供服務器地址。

  • 網關(中繼)IP地址::由DHCP或BOOTP 中繼器填寫,它們在轉發 DHCP(BOOTP)消息時返回自己的地址。

  • 客戶機硬件地址:通常保存客戶機的 MAC 地址,它被用作一個標識符。

  • 服務器名:不是每次都需要填寫,包含 64 字節ASCI 字符,表示服務器名,字符串以 null 結尾

  • 引導文件名:不是每次都需要填寫,包含128 字節ASCI 字符,表示啟動文件路徑,字符串以 null 結尾

  • 選項:長度可變。廣泛應用于DHCP中,以區分DHCP 消息與傳統 BOOTP 消息。

    DHCP 是對 BOOTP 的擴展,DHCP需要的有些字段 BOOTP設計之初是不存在的,這些字段可通過選項來攜帶。

    選項采用標準格式,開始以8位標簽表示選項類型。之后跟著的1字節包含選項值長度(不包括標簽或長度),緊接著是包含選項值自身的可變數量的字節。
    大量選項對于 DHCP 是有效的,其中一些選項也被 BOOTP 支持。常見選項包括:

    • 填充(0)

    • 子網掩碼(1)

    • 路由器地址(3)

    • 域名服務器(6)

    • 域名(15)

    • 請求的IP地址(50)

    • 地址租用期(51)

    • DHCP消息類型(53)

      DHCP消息類型選項(53)是 1 字節長的選項,DHCP消息一定會使用它,它有以下這些可能值:

      • DHCPDISCOVER(1)
      • DHCPOFFER(2)
      • DHCPREQUEST(3)
      • DHCPDECLINE(4)
        DHCPACK(5)
      • DHCPNAK(6)
      • DHCPRELEASE(7)
      • DHCPINFORM(8)
      • DHCPFORCERENEW(9)
      • DHCPLEASEQUERY(10)
      • DHCPLEASEUNASSIGNED(11)
      • DHCPLEASEUNKNOWN(12)
      • DHCPLEASEACTIVE(13)
      • 服務器標識符(54)
    • 參數請求列表(55)

    • DHCP錯誤消息(56)

    • 租約更新時間(58)

    • 租約重新綁定時間(59)

    • 客戶機標識符(61)

    • 域搜索列表(119)

    • 結束(255)

    選項可由 DHCP 消息中的選項字段攜帶,也可以由前面提到的服務器名和引導文件名字段攜帶。當選項攜帶在后兩個位置時,稱為選項超載,將包含一個特殊的超載選項(52)來表明哪些字段適合攜帶選項。對于長度超過255字節的選項,[RFC3396]定義了一種特殊的長選項機制。實際上,如果同一選項在同一消息中重復出現多次,它們的內容按出現在消息中的順序組合,并將結果作為一個選項來處理。如果一個長選項用于表示選項超載,這時的處理順序是從后向前:選項字段、引導文件名字段和服務器名字段。

6.2.4 DHCP協議操作

DHCP 消息是帶有一組特殊選項的 BOOTP 消息。當一臺新的客戶機連接到網絡時,它首先發現可用的 DHCP服務器,以及它們能夠提供的地址。然后,它決定使用哪臺服務器和哪個地址,并向提供該地址的服務器發送請求(同時將其選擇通知所有服務器)。除非服務器在此期間已將該地址分配出去,否則它通過確認將地址分配給請求的客戶機。

image-20250413190737453

  1. 發送請求的客戶機將 BOOTP 的 Op 字段設置為 BOOTREQUEST,并將選項字段的前 4字節分別設置為十進制值 99、130、83 和 99(來自[RFC2132]的魔術 cookie 值)。客戶機向服務器發送消息,使用 UDP/IP 數據報,其中包含一個 BOOTP 的BOOTREQUEST 操作和相應的DHCP消息類型(DHCPDISCOVER)。這種消息從地址0.0.0.0(端口68)發送到受限廣播地址255.255.255.255(端口 67)。其他方向(從服務器到客戶機)的消息從服務器 IP 地址和端口 67 發送到本地 IP廣播地址和端口 68。
  2. 在一次典型的 DHCP交換中,客戶機首先廣播一個 DHCPDISCOVER消息。對于接收到請求的每臺服務器,無論是直接接收還是通過中繼代理,它們都會響應一個DHCPOFFER消息,并在“你的”IP 地址字段中包含提供的 IP 地址。其他配置選項(例如 DNS 服務器的IP地址、子網掩碼)也經常包括在內。DHCPOFFER消息中包含租用時間(T),它提供了在不更新租約的情況下地址可被租用的時間上限。這個消息還包含更新時間(T1),它是客戶機從獲得租約到嘗試要求服務器更新租約的時間,以及重新綁定時間(T2),它是客戶機嘗試要求 DHCP服務器更新其地址的時間。在默認情況下,T1 =(T/2),T2=(7T/8)。
  3. 當接收到來自一臺或多臺服務器的 DHCPOFFER 消息后,客戶機確定自己想接受哪個DHCPOFFER,并廣播一個包括服務器標識符選項的 DHCPREQUEST消息。請求的IP地址選項設置為由選中的DHCPOFFER消息提供的地址。多臺服務器可能接收到廣播的DHCPREQUEST消息,但只有DHCPREQUEST消息中標識的服務器同意將該地址進行綁定;其他服務器清除與該請求相關的狀態。
  4. 在完成綁定后,選中的服務器響應一個DHCPACK消息,通知客戶機現在可使用該地址。如果服務器無法分配包含在DHCPREQUEST 消息中的地址(例如,已通過其他方式分配或無法使用),該服務器將會響應一個 DHCPNAK 消息。
  5. 當客戶機接收 DHCPACK 消息和其他相關的配置信息時,它可探測網絡以確保獲得的地址未被使用(例如,向該地址發送一個 ARP請求以執行 ACD)。如果客戶機確定該地址已被使用,客戶機就不使用該地址,并向服務器發送一個 DHCPDECLINE消息,通知該地址不能使用。在經過默認的10秒延時后,客戶機可重試。如果一臺客戶機在租約到期前放棄該地址,它將發送一個 DHCPRELEASE 消息。
  6. 在客戶機已有一個IP 地址并希望僅更新其租約的情況下,它可跳過最初的DHCPDISCOVER/DHCPOFFER 消息。取而代之的是,客戶機通過一個 DHCPREQUEST 消息請求當前正在使用的地址。此后,協議工作流程如前面所述:服務器可能同意該請求(通過一個DHCPACK),也可能拒絕該請求(通過一個DHCPNAK)。另一種情況,當客戶機已有一個地址時,它不需要更新該地址,但需要其他(非地址的)配置信息。在這種情況下,它可使用DHCPINFORM消息來代替DHCPREQUEST消息,以表明它使用現有地址,但希望獲得額外的信息。這種消息導致服務器返回一個DHCPACK消息,其中包括請求的額外信息。

6.2.4.2 DHCP狀態機

image-20250413193313959

DHCP 協議在客戶機和服務器中運行一個狀態機。狀態用于指出協議下一個處理的消息類型。

上圖描述了客戶機的狀態機。狀態之間的轉換(箭頭)源于消息的接收和發送或超時。如圖所示:

  1. 客戶機開始于INIT(初始)狀態,這時沒有信息,并廣播DHCPDISCOVER 消息。
  2. 在選擇狀態時,它接收 DHCPOFFER消息,直到決定自己使用哪個地址和服務器。
  3. 當它做出選擇時,通過一個DHCPREQUEST消息來響應,并進入請求狀態。
    • 這時,它可能接收來自不需要的地址的ACK。如果它沒有發現需要的地址,發送一個 DHCPDECLINE 消息,并轉換到INIT狀態。
  4. 它接收到一個自己需要的地址的DHCPACK消息,接受它,獲得超時值T1和T2,并進入綁定狀態,這時就能使用這個地址直至到期。
  5. 當第一個計時器(T1)到期時,客戶機進入更新狀態并嘗試重新建立租約。如果它接收到一個新的DHCPACK(客戶機進入綁定狀態),這個過程成功。
    • 如果不成功,T2 最終到期,并導致客戶機嘗試從任意服務器重新獲得一個地址。
    • 如果租用期最終到期,客戶機必須放棄所租用的地址,如果沒有可選的地址或可用的網絡連接,這時它將斷開網絡連接。

6.2.5 DHCPv6

DHCPv6可使用一種“有狀態”模式,其工作原理非常像DHCPv4,它也可以使用一種“無狀態”模式,并結合無狀態地址自動配置,在無狀態模式下,IPv6客戶機認為自己能配置IPv6地址,但需要通過DHCPv6獲得額外信息(例如DNS服務器地址),另一種選擇可使用ICMPv6路由器通告消息獲得一臺DNS 服務器的位置。

6.2.5.1 IPv6地址生命周期

IPv6 主機的每個接口通常擁有多個地址,并且每個地址都擁有一組計時器,以指出相應地址可使用多長時間和用于什么目的。在IPv6中,地址分配包含一個首選生命周期和一個有效生命周期。這些生命周期用于判斷超時,將地址在自己的狀態機中從一種狀態轉換為另一種狀態,如圖。

image-20250413203342878

上圖給出了一個IPv6 地址的生命周期。當一個地址處于首選狀態時,它可用于一般用途,并可作為源或目的IPv6地址。當首選狀態的超時,相應的首選地址將廢棄。當該地址處于廢棄狀態時,它仍可用于現有傳輸(例如TCP)連接,但不能用于啟動新的連接。

當一個地址第一次被選擇使用時,它進入一個臨時或樂觀狀態。在處于臨時狀態時,它可能僅用于IPv6 鄰居發現協議。這時,它不可用作任何其他目的的源或目的地址。同時,該狀態的地址要檢測重復,看看同一網絡中的其他節點是否已使用該地址。這個過程稱為重復地址檢測(DAD)。常規 DAD 的替代方案稱為樂觀DAD[RFC4429],通過它選擇的地址可用于一組有限的用途,直至DAD完成。因為一個樂觀狀態的地址實際上僅是針對DAD的一組特殊規則,它不是一個真正完整的狀態。樂觀地址對大多數目的而言是廢棄的。特別是,一個地址可能同時是樂觀的和廢棄的,這取決于首選生命周期和有效生命周期。

6.2.5.2 DHCPv6 消息格式

DHCPv6消息封裝為UDP/IPv6數據報,它使用客戶機端口546 和服務器端口547。消息發送到中繼代理或服務器,它使用一臺主機的鏈路范圍的源地址。這里存在兩種消息格式,一種用于客戶機與服務器之間,另一種用于中繼代理。

下圖左側給出了基本 DHCPv6 消息格式,右側給出了一種擴展版本,其中包括鏈路地址和對等方地址字段。右側的格式用于DHCPv6中繼代理和DHCPv6服務器之間。鏈路地址字段給出了全局IPv6地址,服務器用它標識客戶機所處的鏈路。對等方地址字段包含中繼代理地址或客戶機地址(要中繼的消息來自該客戶機)。注意,中繼過程可能是鏈狀的,某個中繼可能轉發來自其他中繼的消息。

image-20250413204227519

左側的消息格式中的消息類型包括典型的 DHCP 消息(REQUEST、REPLY 等),右側的消息格式中的消息類型包括 RELAY-FORW 和 RELAY-REPL,分別表示從中繼代理轉發和目的地是中繼代理的消息。右側的選項字段包括一個中繼消息選項,其中包含中繼轉發的完整消息。其他選項也可包含在內。

DHCPv4 和 DHCPv6之間的區別之一是 DHCPv6 使用 IPv6 組播地址的方式。客戶機將請求發送到所有DHCP中繼代理和服務器的組播地址(ff02::1:2)。源地址在鏈路本地范圍。在IPv6中,沒有保留 BOOTP 消息格式。下表給出了DHCPv6的消息類型、取值和定義它的RFC,以及針對DHCPv4的同類消息和定義它的RFC。

image-20250413204610263

在DHCPv6中,最有意義的信息攜帶在選項中,包括地址、租用時間、服務位置,以及客戶端標識符和服務器標識符。這些選項使用的兩個重要概念是:

  • 身份關聯(IA):用在DHCP客戶機和服務器之間的一個標識符,用于指向一個地址集。每個IA包括一個IA標識符(IAID)和相關配置信息。每個請求DHCPv6分配地址的客戶機接口至少需要一個IA。每個IA可以僅與一個接口相關聯。客戶機選擇的IAID唯一地標識每個IA,并將這個值與服務器共享。

    IA 相關的配置信息包括一個或多個地址,以及相關的租約信息(T1、T2和總的租用時間值)。IA 的每個地址都有一個首選的和一個有效的生命周期[RFC4862],它定義了地址的整個生命周期。請求的地址類型可以是常規地址或臨時地址[RFC4941]。臨時地址由隨機數的一部分派生而來,用于協助改善 IPv6 主機地址跟蹤的隱私問題。臨時地址通常與非臨時地址同時分配,但需要頻繁使用不同的隨機數重新生成。

    當服務器響應一個請求時,它為客戶機的IA分配一個或多個地址,分配時基于服務器管理員確定的一組地址分配策略。在通常情況下,這些策略依賴于請求所到達的鏈路、客戶機的標準信息,以及DHCP選項中由客戶機提供的其他信息。

    下圖給出了非臨時地址和臨時地址的IA選項格式。

    image-20250413205108171

    如圖所示,對于非臨時地址和臨時地址的 IA 選項,主要區別是非臨時地址包括T1 和 T2 值。這些值是已知的,它們也是DHCPv4 使用的值。對于臨時地址,可能缺少 T1和 T2,因為生命周期通常基于分配給非臨時地址的 T1 和 T2 值確定,這些值之前是已知的。

  • DHCP唯一標識符(DUID):用于標識一臺DHCPv6客戶機或服務器,并被設計為可持續一段時間。服務器用它標識所選地址(作為IA的一部分)對應的客戶機和配置信息,客戶機用它標識感興趣的服務器。DUID長度是可變的,對于大多數用途來說,客戶機和服務器將它看作一個不透明的值。DUID 是全球唯一的,但它很容易生成。為了同時滿足這些關系,[RFC3315]定義了三種可能的DUID類型,但也不是只能創建這三種類型。三種DUID類型如下:

    1. DUID-LLT:基于鏈路層地址和時間的 DUID。推薦的格式。編碼開始于一個2字節的標識符,用于指出是哪種類型的DUID。緊跟著是一個16位的硬件類型。在硬件類型之后,它包括一個 32位的時間戳,其中的秒數開始于2000年1月1日午夜(UTC)(mod 2^32),它將在2136年歸零(返回0),最后部分是一個可變長度的鏈路層地址。鏈路層地址可由任何主機接口選擇,并使用相同的DUID,一旦選定,它可用于與任何接口的通信。這種格式的DUID是穩定的,即使網絡接口從該DUID中移除。因此,它需要主機系統固定存儲相關信息
    2. DUID-EN:基于企業編號和供應商分配的 DUID。編碼開始于一個2字節的標識符,用于指出是哪種類型的DUID。緊跟著是一個 32 位的專用企業編號
    3. DUID-LL:僅基于鏈路層地址的 DUID。編碼開始于一個2字節的標識符,用于指出是哪種類型的DUID。緊跟著是一個16位的硬件類型。格式與DUID-LLT非常相似,但推薦給缺少固定存儲(但有一個固定的鏈路層地址)的系統。RFC 指出DUID-LL 不能用于某些客戶機或服務器,它們不能確定自己使用的鏈路層地址是否與一個可刪除的接口有關。

6.2.5.5 協議操作

一臺客戶機是否啟用 DHCP,取決于這臺主機接收的 ICMPv6 路由器通告消息中的配置選項。路由器通告包括兩個重要的位字段:

  • M 位是可管理地址配置標志,表示 IPv6 地址可使用 DHCPv6 獲得。

  • O 位是其他配置標志,表示IPv6 地址之外的其他信息可使用 DHCPv6 獲得。

M和O位字段可以任意組合:

  • M啟用和O關閉可能是最不實用的組合。
  • 如果兩者都關閉,則不使用 DHCPv6,并在分配地址時使用無狀態地址自動分配。
  • M關閉和O啟用表示客戶機使用無狀態DHCPv6,并使用無狀態地址自動配置獲得地址。

image-20250413210630407

如圖所示。在通常情況下,一臺客戶機首先確定使用的鏈路本地地址,然后執行ICMPv6 路由器發現操作,以確定所在網絡中是否存在一臺路由器。路由器通告包括前面提到的 M 和 O 位字段。如果正在使用 DHCPv6,則至少設置 M 位字段,并且由客戶機來組播DHCPSOLICIT 消息,以便發現 DHCPv6 服務器。如果存在一個或多個DHCPADVERTISE響應消息,表示至少存在一臺 DHCPv6 服務器。這些消息由 2 次稱為四消息交換的 DHCPv6 操作構成。在已知一臺 DHCPv6 服務器位置,或不需要分配地址(例如無狀態 DHCPv6 或使用快速確認選項)的情況下,“四消息交換”可簡化為“兩消息交換”,在這種情況下只使用請求和應答消息。DHCPv6 服務器確認 DUID、IA類型(臨時、非臨時或前綴)和 IAID 結合而成的綁定。IAID是由客戶機選擇的一個32 位數字。每個綁定可以有一個或多個租約,一個或多個綁定可通過一個 DHCPv6 事務來處理。

6.2.5.7 DHCPv6前綴委托(DHCPv6-PD和6rd)

DHCPv6也可用于配置路由器。這通過一臺路由器向另一臺路由器委托一個地址空間范圍來實現。這個地址范圍可描述為一個IPv6地址前綴。這個前綴在[RFC3633]定義的 DHCP 前綴選項中。這用于路由器委托的情況,它現在可像一個 DHCPv6 服務器那樣工作,而不需要前綴網絡的詳細拓撲信息。這種情況可能發生,例如ISP 給出了一個可由潛在客戶重新分配的地址范圍。在這種情況下,ISP 可能使用 DHCPv6-PD 向客戶設備委托一個前綴。

前綴委托定義了一種新格式的 IA,稱為IA_PD。每個IA_PD 由一個 IAID 和相關的配置信息構成,它在地址上與前面討論的 IA 相似。DHCPv6-PD 不只對固定路由器的前綴委托有用,它也可用于移動路由器(及其連接的子網)[RFC6276]。

目前,已創建一種特殊格式的PD以支持服務提供商快速部署IPv6。在OPTION-6RD(212)選項[RFC5969]中保存IPv6 6rd前綴,它用于根據客戶已分配的IPv4地址為客戶網站分配IPv6地址。IPv6地址是通過算法來分配的,它將服務提供商提供的 6rd 前綴作為前 n 位(推薦 n 小于 32)。客戶分配的單播 IPv4 地址作為后面的 32(或更少)位,這種IPv6 6rd委托前綴同樣可用DHCPv6-PD處理,并推薦64位或更短長度用于自動地址配置。

OPTION_6RD 選項長度可變,包括以下幾個值:IPv4 掩碼長度、6rd 前綴長度、6rd 前綴和 6rd 中繼地址列表(提供6rd 中繼的 IPv4 地址)。IPv4 掩碼長度給出了用于分配 IPv6 地址的 IPv4 地址位數(從左側開始計算)。

6.2.6 使用DHCP中繼

中繼代理用于將 DHCP操作擴展到跨越多個網段。在下圖中,網段 A 和 B 之間的中繼會轉發DHCP消息,并通過選項或填充空白字段使用額外信息來標識消息。注意,在一般情況下,中繼不會參與客戶機和服務器之間的所有DHCP流量交換。相反,它僅中繼那些廣播消息(或IPv6中的組播)。這種消息通常在客戶機首次獲得自己的地址時交換。當一臺客戶機獲得一個IP地址,并且服務器的 IP 地址使用服務器標識選項時,它可與服務器進行單播通信而不經過中繼。注意,中繼代理在傳統上是第3層設備,并且通常結合了路由功能。但在第 2 層也存在可替代操作。

image-20250414175112274

6.2.6.1 中繼代理信息選項

在BOOTP或DHCP中繼的最初概念中,中繼代理的目的只是將一個消息從一個子網中繼到另一個,而不需要經過一臺路由器。這允許系統從一個集中位置不執行間接傳遞就獲得一個地址。在中繼和服務器之間傳遞的消息中需要包含額外信息。中繼代理信息選項(針對DHCPv4,簡稱RAIO)[RFC3046]提供了使IPv4網絡包括這種信息的方法。

DHCPv4 的 RAIO定義在[RFC3046]中,它實際是一個元選項,從某種意義上來說,它僅定義了一個框架,其中可定義許多子選項。很多這樣的子選項已被定義,包括幾個被ISP用于標識一個請求來自哪個用戶、鏈路或網絡的選項。在很多情況下,我們看到DHCPv4信息選項中的每個子選項都有對應的IPv6選項。

子選項例如:

  • 中繼代理遠程ID子選項和IPv6遠程ID選項:

    中繼的共同需求是通過超出客戶機自身提供的信息之外的信息來標識發送 DHCP 請求的客戶機。遠程ID子選項提供了一種標識發送請求的 DHCP 客戶機的方法,即采用一系列本地解釋的命名方法(例如呼叫方 ID、用戶名、調制解調器 ID、一條點到點鏈路的遠程IP 地址)。DHCPv6 中繼代理遠程ID選項[RFC4649]提供了相同的功能,它還包括一個額外的字段(企業編號),以表明與供應商相關的識別信息。這種遠程 ID 信息格式后來以一種基于企業編號的特定供應商方式定義。一種常用的方法是將 DUID 用于遠程 ID。

  • 服務器標識符覆蓋:

    在某些情況下,中繼可能希望干預DHCP客戶機和服務器之間的操作。這可采用一個特殊的服務器標識符覆蓋子選項來實現[RFC5107]。這個子選項是前面提到的RAIO的一個覆選項。

    在通常情況下,一個中繼會轉發SOLICIT消息,并在消息從客戶機傳遞到服務器的過程中,可能為這些消息附加某些選項。中繼在這種情況下是必要的,因為客戶機可能還沒有一個可接受的IP地址,并且僅用廣播或組播方式將消息發送到本地子網。當一臺客戶機接收并選擇自己的地址之后,它可使用服務器標識符選項中攜帶的服務器標識直接與DHCP服務器通信。實際上,這將削弱中繼在客戶機和服務器之間后續事務中的作用。允許中繼為不同類型的消息(例如除了SOLICT 外的 REQUEST)提供不同選項(例如RAIO 攜帶一個電路 ID),這通常是有用的。這種選項包括一個 4 字節的值,以指定服務器生成的DHCPREPLY消息中的服務器標識符選項中使用的IPv4地址。服務器標識符覆蓋選項建議與中繼代理標志子選項一起使用[RFC5010]。這個RAIO的子選項是一組標志,它們可攜帶從中繼到服務器的信息。到目前為止,只有一個關于這種標志的定義:客戶機是否使器用廣播或單播地址作為初始消息中的目的地址。服務器可能根據這個標志設置做出不同的地址分配決定。

  • 租約查詢:

    在某些環境下,允許第三方系統(如中繼或接入集中器)學習一個特定DHCP客戶機的地址綁定是有用的。這個功能由DHCP租約查詢(針對DHCPv4的[RFC4388],[RFC6148],或針對DHCPv6的[RFC5007])來提供。

    在DHCPv6中,它也可為委托前綴提供租約信息。在上圖中,中繼代理可能從經過的 DHCP 分組中“搜集”信息,以影響那些提供給DHCP服務器的信息。這些信息可能由中繼保存,但也可能在中繼失敗時丟棄。

    DHCPLEASEQUERY 消息允許一個代理根據需要重新獲得這種信息,它通常發生在一個中繼流量已失去綁定的情況下。對于 DHCPv4,DHCPLEASEQUERY 消息支持 4 種查詢:IPv4地址、MAC地址、客戶機標識符和遠程ID。對于DHCPv6,它支持兩種查詢:IPv6地址和客戶機標識符(DUID)。

    DHCPv4服務器可能用以下幾種消息響應租約查詢:

    • DHCPLEASEUNASSIGNED:指出該查詢值的響應服務器是授權的,但目前沒有分配相應租約。
    • DHCPLEASEACTIVE或DHCPLEASEUNKNOWN:表示一個租約是有效的,并提供了租約參數(包括 T1 和 T2)。這里沒有對此信息用途的特定建議,無論出于何種目的,都希望提供給請求者。

    DHCPv6服務器使用一個LEASEQUERY-REPLY消息來響應:

    其中包含一個客戶機數據選項。這個選項依次包括以下選項:客戶機ID、IPv6地址、IPv6前綴和客戶機的最后事務時間。最后一個值是服務器最后一次詢問客戶機的時間(以秒為單位)。LEASEQUERY-REPLY 消息也可包含以下兩個選項:中繼數據和客戶機鏈路。第一個選項包括中繼最后一次發送的相關查詢的數據,第二個選項指出特定客戶機擁有一個或多個地址綁定的鏈路。

  • 大批量租約查詢

    租約查詢的擴展稱為大批量租約查詢(BL),它可以同時查詢多個綁定關系,使用 TCP/IP而不是 UDP/IP,并支持更大范圍的查詢類型。BL 被設計為一種獲得綁定信息的特定服務,它實際上不是傳統 DHCP 的一部分。因此,客戶機可能希望不使用BL 而獲得常規配置信息。BL的一個特殊用途表現在 DHCP 用于前綴委托時。在這種情況下,最常見的是一臺路由器作為一個 DHCP-PD 客戶機使用。它獲得一個前綴,并從該前綴代表的一個地址范圍中獲得一個地址,以分配給傳統的DHCP客戶機。但是,如果一臺路由器出現故障或重新啟動,它可能會丟失這個前綴信息,并在一段時間內難以恢復,這是因為傳統的租約查詢機制需要綁定一個用于查詢的標識符。BL有助于緩解這種情況。

    BL提供了對基本租約查詢的幾個擴展。首先,它使用TCP/IP(用于IPv6的端口547和用于IPv4的端口67)而不是UDP/IP。這種改變使一次查詢可獲得大量查詢信息,這在檢索大量委托前綴時是必要的。BL 也提供了一個中繼標識符選項,允許查詢者更容易地識別查詢。BL 查詢可基于中繼標識符、鏈路地址(網段)或中繼 ID。
    DHCPv6中繼ID選項和DHCPv4中繼ID子選項可能包括一個用于標識中繼代理的 DUID。中繼可在自己轉發的消息中插入這個選項,服務器可用它關聯自己接收的由特定中繼提供的綁定。BL支持基于地址和DUID的查詢,也支持基于中繼 ID、鏈路地址和遠程 ID 的查詢。這些新查詢只被基于 TCP/IP 并支持 BL 的服務器所支持。相反,BL 服務器僅支持 LEASEQUERY 消息,而不是整套的普通 DHCP 消息。

    BL 通過 LEASEQUERY-DATA 和 LEASEQUERY-DONE 消息擴展基本的租約查詢機制。當一個查詢被成功響應時,一臺服務器首先返回一個 LEASEQUERY-REPLY 消息。如果附加信息是可用的,那么它包括一組 LEASEQUERY-DATA 消息,每個消息對應一個綁定,并通過一個 LEASEQUERY-DONE 消息來完成設置。屬于相同綁定組的所有消息共享相同的事務ID,每個相同值由初始的LEASEQUERY REQUEST消息提供。

6.2.6.5 第2層中繼代理

在一些網絡環境中,第 2 層設備(例如交換機、網橋等)更靠近端系統,它們會中繼和處理DHCP請求。這些第2 層設備沒有完整的TCP/IP協議棧,并且不使用IP進行尋址。因此,它們不能作為傳統的中繼代理。

為了解決這個問題,[IDL2RA]和[RFC6221]分別針對IPv4和IPv6規定了第2層“輕量級”DHCP中繼代理(LDRA)如何工作。當針對中繼行為時,接口被標記為面向客戶或面向網絡,以及可信或不可信。面向網絡的接口在拓撲結構上更接近 DHCP 服務器,可信的接口是那些假設到達的分組不存在欺騙的接口。

IPv4 LDRA 的首要問題是如何處理 DHCP 的 giaddr 字段,以及在 LDRA 本身沒有 IP 層信息時插入一個RAIO。[IDL2RA]推薦的方法是:LDRA在客戶機接收的DHCP 請求中插入 RAIO,但不填寫 giaddr 字段。DHCP 消息以廣播方式發送給一個或多個 DHCP 服務器,以及其他處于接收狀態的LDRA。這種消息一直被洪泛(即在所有接口上發送,除了獲得該消息的接口),直到被一個不可信的接口接收。當 LDRA 接收到一個包含 RAIO的這種消息,它不會添加其他的同類選項,但會繼續執行洪泛。通過廣播發送的響應(例如DHCPOFFER消息)可能被 LDRA 攔截,這時需要剝離 RAIO 并使用其中的信息,以便將響應發送給發出請求的客戶機。很多 LDRA 也攔截單播的 DHCP 流量。在這些情況下,創建或剝離 RAIO也是必要的。注意,兼容的 DHCP 服務器必須支持處理和返回這樣的DHCP 消息:無論是用單播發送還是廣播發送,其包含的RAIO中沒有有效的giaddr 字段。

IPv6的LDRA通過創建RELAY-FORW和RELAY-REPL消息處理DHCPv6流量。面向客戶的接口將會丟棄接收到的ADVERTISE、REPLY、RECONFIGURE和RELAY-REPL消息。另外,不可信的面向客戶的接口也會出于安全原因丟棄接收到的RELAY-FORW 消息。RELAY-FORW消息包含標識面向客戶接口的選項(即鏈路地址字段、對等方地址字段和接口 ID 選項)。鏈路地址字段設置為 0,對等方地址字段設置為客戶機 IP 地址,接口 ID選項設置為LDRA 中配置的值。當接收到一個鏈路地址字段為 0 的 RELAY-REPL 消息時,LDRA 解封所包含的信息,并將其發送到由接口 ID 選項(由服務器提供)指定的客戶機接口。面向客戶的接口修改接收的RELAY-FORW消息的跳步數。面向網絡的接口將會丟棄接收的除RELAY-REPL之外的消息。

6.2.9 快速確認

DHCP 快速確認選項[RFC4039]允許一臺 DHCP 服務器通過一個 DHCPACK 來響應DHCPDISCOVER 消息,從而有效跳過 DHCPREQUEST消息,并最終使用兩消息交換來代替四消息交換。這個選項的設計目的是快速配置可能頻繁改變其網絡接入點的主機(例如移動主機)。當僅有一臺可用的 DHCP服務器并且地址充足時,我們可以不關注這個選項。

要使用快速確認,客戶機可在 DHCPDISCOVER 消息中包含該選項,但在任何其他消息中不能包含該選項。同樣,服務器僅在DHCPACK消息中使用該選項。當一臺服務器使用該選項來響應時,接收消息的客戶機知道該返回地址可立即使用。如果后來確定該地址已用于另一個系統(例如通過ARP),客戶機發送一個DHCPDECLINE消息,并放棄該地址。客戶機也可能通過一個 DHCPRELEASE 消息自愿放棄接收到的地址。

6.2.10 位置信息(LCI和LoST)

IETF 的一個眾所周知的成果是 Geoconf(“地理配置”)[RFC6225],[RFC6225]規定了如何使用GeoConf(123)和GeoLoc(144)的DHCP選項,為客戶機提供這種地理空間位置配置信息(LCI)。地理空間 LCI 不僅包括緯度、經度和高度坐標,也為每個信息提供分辨率指標。LCI 可用于一系列目的,包括緊急服務。如果一個呼叫者使用 IP 電話請求緊急援助,LCI 可指示發生緊急情況的位置。

盡管剛提到的物理位置信息對找到特定的個人或系統是有用的,但有時知道一個實體的市政位置也是重要的。市政位置根據行政地理表示位置,例如國家、城市、區、街道,以及其他類似的參數。市政位置信息可通過 DHCP 以物理位置所采用的方式提供,使用的 LCI結構與地理空間 LCI 中使用的一樣。[RFC4776]定義了攜帶市政位置的 GEOCONF_CIVIC(99)選項。這種格式的LCI比地理空間信息更麻煩,這是因為各個國家在行政地理上命名位置的方法不同。由于這種名稱除了需要 DHCP 常用的英語、ASCII 語言和字符集外,可能還需要其他語言和字符集的支持,這會帶來額外的復雜性。不僅是DHCP方面,這里還存在位置的隱私問題。IETF在 Geopriv 框架中討論了這個問題。例如,參見[RFC3693]了解更多信息。

一個可供選擇的高層協議稱為啟用HTTP的位置投遞(HELD)協議[RFC5985],它可用于提供位置信息。代替在 DHCP 消息中直接編碼 LCI,而是采用 DHCP 選項 OPTION_V4_ACCESS_DOMAIN(213)和 OPTION_V6_ACCESS_DOMAIN(57)分別為 IPv4 和 IPv6 提供一臺 HELD 服務器的 FQDN[RFC5986]。
當一臺主機知道自己的位置時,它可能需要使用該位置的相關服務(例如位置最近的醫院)。IETF的位置到服務轉換(LoST)框架[RFC5222]通過一個使用位置相關URI訪問的應用層協議來實現上述功能。DHCP 選項 OPTION_V4_LOST(137)和 OPTION_V6_LOST(51)為一個 FQDN 提供可變長度的編碼,FQDN 分別為 DHCPv4 和 DHCPv6 指定一臺 LoST 服務器的名稱[RFC5223]。這個編碼與 DNS 的域名編碼采用相同格式。

6.2.11 移動和切換信息(MoS和ANDSF)

隨著使用移動計算機和智能手機通過蜂窩技術訪問Internet的用戶逐漸增多,定義了有關蜂窩配置和不同無線網絡之間切換的框架和相關 DHCP 選項。目前,存在兩套有關該信息的DHCP選項:

  • IEEE 802.21 移動服務(MoS)發現:

    MoS提供了3種類型的服務:信息服務、命令服務和事件服務。粗略地說,這些服務提供了有關可用網絡、控制鏈路參數功能和鏈路狀態變化通知的信息。MoS發現DHCP選項[RFC5678]為移動節點獲得地址或域名提供了一種手段,無論提供這些服務的服務器使用 DHCPv4還是 DHCPv6。對于 IPv4,OPTION-IPv4_Address-
    MoS選項(139)包含一個子選項的向量,其中包含提供每種服務的服務器的IP地址。OPTION-IPv4_FQDN-MoS 選項(140)的一個子選項為每種服務的服務器提供了一個 FQDN向量。其他類似選項有OPTION-IPv6_Address-MoS(54)和OPTION-IPv6_FQDN(55),它們為 IPv6 提供了同等功能。

  • 接入網發現和選擇功能(ANDSF):

    基于 3GPP 的 ANDSF 規范,[RFC6153]定義了攜帶 ANDSF 信息的 DHCPv4 和 DHCPv6選項。特別是,它定義了移動設備發現ANDSF服務器地址的選項。ANDSF服務器由蜂窩基礎設施運營商來配置,并可能保存多種傳輸網絡(例如同時使用3G和Wi-Fi)的可用性和訪問策略等信息。

    ANDSF IPv4 地址選項(142)包含一個ANDSF服務器的IPv4地址向量。這些地址按優先順序(第一個是最合適的)提供。ANDSF IPv6地址選項(143)包含一個ANDSF服務器的IPv6地址向量。要使用DHCPv4請求ANDSF信息,移動節點可在參數請求列表中包括ANDSF IPv4 地址選項。要使用DHCPv6請求ANDSF信息,客戶機可在選項請求選項(ORO)中包含ANDSF IPv6地址選項。

6.3——無狀態地址自動配置

大多數路由器通過手動配置地址,主機既可手動配置地址,也可使用一種如DHCP 的分配協議或某種算法來自動配置地址。這里存在兩種形式的自動配置,它們取決于需要生成什么類型的地址。對于只用于一條鏈路的地址(鏈路本地地址),一臺主機只需找到一些在鏈路上未使用的合適地址。但是,對于要用于全球性連接的地址,這類地址的某些部分通常必須被管理。IPv4 和 IPv6都有用于鏈路本地地址自動配置的機制,一臺主機基本不需要協助就可以決定自己的地址。這就是所謂的無狀態地址自動配置(SLAAC)。

6.3.1 IPv4鏈路本地地址的動態配置

在一臺主機沒有任何手工配置的地址,并且所在網絡沒有DHCP服務器的情況下,基于IP的通信是不可能發生的,除非主機使用某種方式生成IP地址。[RFC3927]描述了一種機制,主機通過該機制可自動從鏈路本地范圍169.254.1.1至169.254.254.254使用16位子網掩碼255.255.0.0生成自己的IPv4地址(見[RFC5735])。這種方法稱為鏈路本地地址的動態配置或自動專用IP尋址(APIPA)。從本質上來說,就是一臺主機從一個范圍中隨機選擇一個地址,并檢查該地址是否已在本子網中被其他系統使用。這種檢查通過IPv4 ACD來實現。

6.3.2 鏈路本地地址的IPv6 SLAAC(無狀態地址自動配置)

IPv6 SLAAC的目標是允許節點自動(和自主)分配鏈路本地IPv6 地址。[RFC4862]中描述了IPv6 SLAAC。它包括 3 個主要步驟:

  1. 獲得一個鏈路本地地址
  2. 使用無狀態自動配置獲取全球地址
  3. 檢測鏈路本地地址是否已在鏈路中使用。

無狀態自動配置可用于沒有路由器的環境,在這種情況下只分配鏈路本地地址。當路由器存在時,由一個路由器通告的前綴和本地產生的信息組合成一個全球地址。SLAAC也可結合DHCPv6(或手動分配地址)使用,以允許一臺主機獲得除自己地址外的其他信息(稱為“無狀態”DHCPv6)。當網絡采用有狀態或無狀態 DHCPv6配置時,執行SLAAC的主機可用于同一網絡中。在通常情況下,有狀態DHCPv6用于需要為主機更精確分配地址時,但無狀態DHCPv6和SLAAC結合是最常見的部署選擇。

在IPv6中,臨時(或樂觀)鏈路本地地址由[RFC4291]和[RFC4941]規定的過程來選擇。它們只用于具有組播能力的網絡,并在建立時分配了極大的首選和有效生命周期。為了形成數字化的地址,在熟知的鏈路本地前綴 fe80::0(適當長度)之后附加了一個唯一的編號。這是通過將地址中最右邊的N位設為N位數字,最左邊的10位設為10位鏈路本地前綴1111111010,并且其余位設為0來實現的。生成的地址設置為臨時(或樂觀)狀態,并檢查該地址是否重復。

6.3.2.1 IPv6重復地址檢測(DAD)

IPv6 DAD 使用 ICMPv6 鄰居請求和鄰居通告消息,以確定一個特定(臨時或樂觀)IPv6地址是否已在連接鏈路上使用。本次討論只針對臨時地址,但DAD也適用于樂觀地址。[RFC4862]中定義了DAD,并建議在為一個接口分配IPv6地址時使用,無論手動分配還是自動配置或DHCPv6分配。如果發現地址重復,將不使用該臨時地址。如果DAD 成功,臨時地址轉換為優先狀態,并可不受限制地使用。

DAD 按以下步驟執行:一個節點首先加入臨時地址的所有節點組播地址和請求節點組播地址。為了檢查使用的地址是否重復,一個節點發送一個或多個ICMPv6 鄰居請求消息。這些消息的源和目的IPv6地址分別是未指定地址和被檢查目的地址的請求節點地址。目的地址字段設置為被檢查的地址(臨時地址)。如果在響應中接收到一個鄰居通告消息,說明 DAD 失敗,并放棄被檢查的地址。當一個地址未成功完成DAD時,任何針對它的鄰居請求被視為一種特殊情況,說明其他主機有使用相同地址的意圖。如果接收到這些消息,丟棄它們,放棄當前的臨時地址,并且 DAD 失敗。

如果 DAD失敗,通過接收一個來自其他節點的鄰居請求或一個到目的地址的鄰居通告,說明這個地址未分配給一個接口,并且不會成為一個首選地址。如果這個地址是一個基于由本地MAC地址導出的接口標識符配置的鏈路本地地址,不可能通過相同過程最終生成一個不沖突的地址,這時應放棄使用該地址并要求管理員輸入地址。如果這個地址是基于不同形式的接口標識符,IPv6操作可能嘗試使用基于別的臨時地址的其他地址。

6.3.2.2 全球地址的IPv6 SLAAC

在一個節點已獲得一個鏈路本地地址后,它可能需要一個或多個全球地址。全球地址的形成過程類似于鏈路本地SLAAC,但需要使用一個由路由器提供的前綴。這種前綴攜帶在一個路由器通告的前綴選項中,并且由一個標志來表示這個前綴是否用于與SLAAC共同形成全球地址。如果是,這個前綴與接口標識符(如果不采用隱私擴展方式,它與形成鏈路本地地址相似)組合形成一個全球地址。這種地址的首選和有效生命周期也由前綴選項表示的信息來確定。

6.3.2.4 無狀態DHCP

DHCPv6 可用于一種“無狀態”模式,在這種模式下,DHCPv6 服務器不指定地址(或保留任何一臺客戶機的狀態),但提供其他配置信息。無狀態DHCPv6定義在[RFC3736]中,并將SLAAC和DHCPv6相結合。

在一個無狀態 DHCPv6 部署方案中,假設節點采用DHCPv6之外的方法獲得自己的地址。因此,DHCPv6 服務器不需要處理定義在表 6-1 中的地址管理消息。另外,它不需要處理建立IA綁定所需的選項。這大大簡化了服務器軟件和配置工作。中繼代理的操作沒有改變。

無狀態 DHCPv6 客戶機使用 DHCPv6 的 INFORMATION-REQUEST 消息請求信息,該信息由服務器發送的 REPLY 消息提供。INFORMATION-REQUEST 消息包含一個選項請求選項,給出客戶機想了解的更多信息的選項。INFORMATION-REQUEST 可能包含一個客戶機標識符選項,它允許為特定的客戶機定制答案。為了實現標準的無狀態DHCPv6服務器,相應系統必須實現以下這些消息:

  • INFORMATION-REQUEST
  • REPLY
  • RELAY-FORW
  • RELAY-REPL

它還必須實現以下這些選項:

  • 選項請求
  • 狀態代碼
  • 服務器標識符
  • 客戶機消息、服務器消息和接口ID:這三個選項在作為中繼代理時使用。

作為一臺可用的無狀態 DHCPv6 服務器,以下幾個選項也是必要的:

  • DNS 服務器
  • DNS 搜索列表
  • 可能的SIP 服務器

其他可能有用但不是必需的選項主要包括:優先級、經歷的時間、用戶類別、供應商類別、供應商特定信息、客戶機標識符和認證。

6.4——DHCP和DNS交互

當一臺 DHCP 客戶機獲得一個 IP 地址時,它接收的配置信息的重要部分是一臺 DNS服務器的IP地址。它允許客戶機系統將DNS名稱轉換為IPv4和/或IPv6地址,該地址是進行傳輸層連接時協議實現所需要的。如果沒有 DNS 服務器或其他方式將域名映射為IP地址,大多數用戶會發現他們幾乎難以訪問互聯網系統。如果本地DNS工作正常,它將Internet 作為一個整體來提供地址映射,但如果配置正確,也可針對本地的專用網絡(如前面提到的.home)。
由于本地專用網絡的 DNS 映射通常采用煩瑣的手工管理,因此,將指定DHCP地址與相應地址的DNS映射更新方法結合起來將會帶來方便。這可通過組合DHCP/DNS服務器或動態 DNS來實現。

組合 DNS/DHCP 服務器(如 Linux dnsmasq包)是一個服務器程序,它可配置為提供 IP地址租約以及其他信息,也可讀取一個DHCPREQUEST中的客戶機標識符或域名,并在使用DHCPACK進行響應之前,通過“名稱到地址”的綁定更新內部 DNS數據庫。這樣,由DHCP 客戶機或與相同 DNS 服務器交互的其他系統發起的任何后續 DNS 請求,能夠在客戶機名稱和新分配的IP 地址之間轉換。

6.5——以太網上的PPP

對于大多數局域網和一些廣域網連接,DHCP提供了最常用的客戶機系統配置方法。

對于廣域網連接(例如 DSL),常用另一種基于 PPP 的方法代替它。這種方法涉及在以太網中攜帶PPP,因此稱為以太網上的PPP(PPPoE),PPPoE用于廣域網連接設備(例如DSL調制解調器)作為一個交換機或網橋而不是使用路由器的情況下。PPP作為某些ISP建立連接的首選,這是因為它可提供比其他配置選項(例如DHCP)更細致的配置控制和審計日志。為了提供Internet連接,有些設備(例如用戶PC)必須實現 IP 路由和尋址功能。下圖顯示了典型的使用情況。

image-20250414212902138

該圖顯示了一個ISP 使用DSL為很多客戶提供服務。DSL提供一條點到點的數字鏈路,DSL調制解調器為 PPP 端口提供橋接服務,該端口位于ISP的接入集中器(AC)中,連接客戶的調制解調器線和 ISP 的網絡設備。調制解調器和 AC 也支持 PPPoE協議,在這個例子中,該用戶選擇將一臺家用 PC 連接到 DSL 調制解調器,并使用一個點到點的以太網絡(即僅使用一根電纜的以太網)。

在 DSL 調制解調器與 ISP 成功建立一條低層鏈路后,PC 可以開始進行 PPPoE交換,它被定義在信息文檔[RFC2516]中,如下圖所示。

image-20250414213303026

這個協議包括一個發現階段和一個 PPP 會話階段。發現階段涉及交換幾個PPPoE 主動發現(PAD)消息:

  • PADI(初始化)
  • PADO(提供)
  • PADR(請求)
  • PADS(會話確認)。

在這個交換完成后,由以太網封裝的一次PPP會話開始,并最終由任何一方發送PADT(終止)消息來終止。如果低層連接中斷,這個會話也會終止。

PPPoE 消息使用下圖所示的格式,并封裝在以太網的有效載荷區。

image-20250414213520756

  • PPPoE版本和類型:長度都是 4 位,并包含當前PPPoE 版本的值0x1。

  • 代碼:包含 PPPoE 消息類型的提示,如圖的右下部分所示。

  • 會話 ID 字段包含值 0x0000 表示 PADI、PADO 和 PADR 消息,并在后續消息中包含一個唯一的 16 位數字。在 PPP 會話階段會保持相同的值。

  • PAD 消息包含一個或多個標簽,它們按 TLV 方式排列為一個 16 位的 TAG_TYPE 字段,隨后是一個 16 位的 TAG_LENGTH 字段和一個數據可變的標簽值。下表給出了TAG_TYPE字段的值和含義。

    image-20250414213826622

一次PPP會話開始,并最終由任何一方發送PADT(終止)消息來終止。如果低層連接中斷,這個會話也會終止。

PPPoE 消息使用下圖所示的格式,并封裝在以太網的有效載荷區。

[外鏈圖片轉存中…(img-RSGACKuo-1744638406646)]

  • PPPoE版本和類型:長度都是 4 位,并包含當前PPPoE 版本的值0x1。

  • 代碼:包含 PPPoE 消息類型的提示,如圖的右下部分所示。

  • 會話 ID 字段包含值 0x0000 表示 PADI、PADO 和 PADR 消息,并在后續消息中包含一個唯一的 16 位數字。在 PPP 會話階段會保持相同的值。

  • PAD 消息包含一個或多個標簽,它們按 TLV 方式排列為一個 16 位的 TAG_TYPE 字段,隨后是一個 16 位的 TAG_LENGTH 字段和一個數據可變的標簽值。下表給出了TAG_TYPE字段的值和含義。

    [外鏈圖片轉存中…(img-lwnmxp3d-1744638406647)]

本文來自互聯網用戶投稿,該文觀點僅代表作者本人,不代表本站立場。本站僅提供信息存儲空間服務,不擁有所有權,不承擔相關法律責任。
如若轉載,請注明出處:http://www.pswp.cn/web/75853.shtml
繁體地址,請注明出處:http://hk.pswp.cn/web/75853.shtml
英文地址,請注明出處:http://en.pswp.cn/web/75853.shtml

如若內容造成侵權/違法違規/事實不符,請聯系多彩編程網進行投訴反饋email:809451989@qq.com,一經查實,立即刪除!

相關文章

聯想電腦開機出現Defalut Boot Device Missing or Boot Failed怎么辦

目錄 一、恢復bios默認設置 二、關機重啟 三、“物理”方法 在圖書館敲代碼時,去吃了午飯回來發現剛開機就出現了下圖的問題(崩潰),想起之前也發生過一次 這樣的問題,現在把我用到的方法寫在下面,可能對…

用戶登陸UI

本節任務 完成用戶登陸UI,點擊登陸按鈕跳轉到應用主頁 界面原型: 登陸頁面: 登陸成功頁面: 涉及知識點: 線性布局Image組件輸入框復選框分割線按鈕路由跳轉背景色、內容對齊 1 新建項目 錄入項目信息:…

linux多線(進)程編程——(1)前置知識

liunx多線程編程(前置知識)前置知識 前言 學習編程就像是修仙,分為宗門的正統修士(計算機專業的學生),以及野修(半路轉碼)。正統修士有各大宗門的功法,保證一路修行暢通…

Npfs!NpFsdCreate函數分析之從NpCreateClientEnd函數分析到Npfs!NpSetConnectedPipeState

第一部分: 1: kd> g Breakpoint 5 hit Npfs!NpFsdCreate: baaecba6 55 push ebp 1: kd> kc # 00 Npfs!NpFsdCreate 01 nt!IofCallDriver 02 nt!IopParseDevice 03 nt!ObpLookupObjectName 04 nt!ObOpenObjectByName 05 nt!IopCreateFile 06…

【軟件測試】bug 篇

本章思維導圖: 1. 軟件測試的生命周期 軟件測試貫穿于整個軟件的生命周期 流程階段需求分析測試計劃測試設計/開發測試執行測試評估上線運行維護具體工作內容1. 閱讀需求文檔 2. 標記可測試需求 3. 確定測試類型1. 制定測試范圍 2. 選擇測試工具 3. 分配資源1. 編寫…

「Unity3D」圖片導入選項取消Read/Write,就無法正確顯示導入大小,以及Addressable打包無法正確顯示的問題

如果在Edit -> Project Settings -> Editor中的“Load texture data on demand”勾選,就會讓圖片導入設置中,不勾選Read/Write,就無法正確顯示紋理的大小數字。 更進一步的問題是,使用Addressable打包的時候, 如…

《MySQL從入門到精通》

文章目錄 《MySQL從入門到精通》1. 基礎-SQL通用語法及分類2. 基礎-SQL-DDL-數據庫操作3. 基礎-SQL-DDL-表操作-創建&查詢4. 基礎-SQL-DDL-數據類型及案例4.1 數值類型4.2 字符串類型4.3 時間和日期類型 5. 基礎-SQL-DDL-表操作-修改&刪除5.1 DDL-表操作-修改5.2 DDL-表…

Vccaux_IO在DDR3接口中的作用

一、Vccaux_IO在DDR3接口中的作用 1.vccaux_io通常為FPGA的IO bank的輔助電源,用于支持特定電壓的IO標準 2.在DDR3接口中,FPGA的IO bank需要DDR3芯片的電壓(1.5v/1.35v)匹配 3.Vccaux_IO用于為FPGA的DDR3接口I/O Bank供電,其電壓值、噪聲和穩…

深入理解Apache Kafka

引言 在現代分布式系統架構中,中間件扮演著至關重要的角色,它作為系統各組件之間的橋梁,負責處理數據傳遞、消息通信、負載均衡等關鍵任務。在眾多中間件解決方案中,Apache Kafka憑借其高吞吐量、低延遲和可擴展性,已…

【NLP】 21. Transformer整體流程概述 Encoder 與 Decoder架構對比

1. Transformer 整體流程概述 Transformer 模型的整個處理流程可以概括為從自注意力(Self-Attention)到多頭注意力,再加上殘差連接、層歸一化、堆疊多層的結構。其核心思想是利用注意力機制對輸入進行并行計算,從而避免傳統 RNN …

路由器端口映射的意思、使用場景、及內網ip讓公網訪問常見問題和解決方法

一、端口映射是什么意思 端口映射是將內網主機的IP地址端口映射到公網中,內部機器提供相應的互聯網服務。當異地用戶訪問該這個端口時,會自動將請求映射到對應局域網內部的機器上。 二、端口映射常見使用場景 1,遠程訪問需求。當有…

GEO全域優化白皮書:盈達科技如何打造AI生態中的認知護城河

副標題:讓內容被AI優先引用,占領生成式引擎的“主屏入口” 一、GEO:生成式引擎時代的內容占位權之戰 隨著ChatGPT、Kimi、DeepSeek等生成式AI快速成為信息獲取的主流方式,搜索邏輯正在根本性改變:從“網頁排名”轉向“…

如何用DeepSeek大模型提升MySQL DBA工作效率?實戰案例解析

如何用DeepSeek大模型提升MySQL DBA工作效率?實戰案例解析 MySQL DBA(數據庫管理員)的工作涉及數據庫監控、SQL優化、故障排查、備份恢復等復雜任務,傳統方式依賴手動操作和經驗判斷,效率較低。而DeepSeek大模型可以結…

系統設計思維的討論

我們經常說自己熟悉了spring,能夠搭建起一個項目基本框架,并且在此之上進行開發,用戶or客戶提出需求碰到不會的百度找找就可以實現。干個四五年下一份工作就去面試架構師了,運氣好一些可能在中小公司真的找到一份架構師、技術負責…

項目部署-(二)Linux下SpringBoot項目自動部署

一、項目部署架構 二、項目部署環境 192.168.138.100(服務器A): -Nginx :部署前端項目、配置反向代理 -MySQL:主從復制結構中的主庫 192.168.138.101(服務器B): -JDK:運行Java項目 -Git:版本控制工具 -Maven:項目構建…

【LeetCode 熱題 100】哈希 系列

📁1. 兩數之和 本題就是將通過兩層遍歷優化而成的,為什么需要兩層遍歷,因為遍歷 i 位置時,不知道i-1之前的元素是多少,如果我們知道了,就可以通過兩數相加和target比較即可。 因為本題要求返回下標&#xf…

【Kubernetes基礎】--查閱筆記1

目錄 Kubernetes 是什么為什么要用 KubernetesKubernetes 概念MasterNodePodLabelReplication ControllerDeploymentHorizontal Pod AutoscalerStatefulSetService服務發現機制 JobVolumePersistent VolumeNamespaceConfigmap Kubernetes 是什么 Kubernetes是一個開放的開發平…

卷積神經網絡CNN到底在卷些什么?

來源: 卷積神經網絡(CNN)到底卷了啥?8分鐘帶你快速了解!_嗶哩嗶哩_bilibili卷積神經網絡(CNN)到底卷了啥?8分鐘帶你快速了解!共計2條視頻,包括:卷…

Axios 的 POST 請求:QS 處理數據的奧秘與使用場景解析

在現代前端開發中,Axios 已經成為了進行 HTTP 請求的首選庫之一,它的簡潔易用和強大功能深受開發者喜愛。當使用 Axios 進行 POST 請求時,我們常常會遇到一個問題:是否需要使用 QS 庫來處理請求數據?什么時候又可以不用…

java面試題帶答案2025最新整理

文章目錄 一、java面試題集合框架1. 請簡要介紹 Java 集合框架的體系結構2. ArrayList 和 LinkedList 的區別是什么3. HashMap 的工作原理是什么,它在 JDK 7 和 JDK 8 中有哪些不同4. 如何解決 HashMap 的線程安全問題5. TreeSet 是如何保證元素有序的 二、java面試…