本備忘錄的狀態
本文檔講述了一種Internet社區的Internet標準跟蹤協議，它需要進一步進行討論和建
議以得到改進。請參考最新版的“Internet架構委員會正式協議標準”來獲得本協議的標準
化程度和狀態。本備忘錄的發布不受任何限制。
版權聲明
Copyright(C)TheInternetSociety(2000)。版權所有。
摘要
IEEE1394-1995標準是一個高速串行總線的標準。因為1394使用一種和常規的IEEE
802/Ethernet不同的鏈路層編址方式，必須澄清一些字段的用法來實現互操作性。本文檔詳
細描述了1394DHCP消息中一些字段的具體用法。

目錄
1.介紹 2
2.有關1394鏈路地址的問題 2
3.DHCP消息字段的1394非凡應用 2
4.安全因素 3
致謝 3
參考文獻 3
作者地址： 3
完整的版權聲明 3
致謝 4




1.介紹
IEEE1394-1995標準是一個高速串行總線的標準。IETFip1394工作組具體描述了在
IEEE1394網絡中運載IPv4數據報和1394ARP包[RFC2734]的方法。
動態主機配置協議(DynamicHostConfigurationPRotocol，縮寫為DHCP)[RFC2131]提
供了一種構架，來給TCP/IP網絡中的主機提供臨時的配置信息。
Since1394采用了一種和常規的IEEE802/Ethernet不同的鏈路層編址方法，為了實現
互操作性，必須澄清一些字段的用法。本備忘錄敘述了1394中關于DHCP的一些字段的詳
細用法。DHCP機制和每個字段的注解見[RFC2131]。
在RFC2119[RFC2119]中解釋了本文檔中的要害詞“必須”、“不應該”、“必要的”、“應
該”、“不必”、“推薦”、“可以”和“選擇”的含義。
2.有關1394鏈路地址的問題
With通常的鏈路層協議，就象Ethernet那樣，“chaddr”(客戶機硬件地址)字段用于從
DHCP服務器(或中繼代理)向客戶機返回應答消息。因為1394鏈路地址(節點ID)是臨時的，
而且在穿越1394網橋時會不一致，所以我們已經決定不把它放入“chaddr”字段。當1394
ARP也沒有可能時，DHCP客戶機應該通過設置廣播標記請求服務器發送一個廣播應答。
注重：通常，不鼓勵使用廣播應答，但是我們認為，在1394網絡中，碰撞不是問題。
3.DHCP消息字段的1394非凡應用
當一臺DHCP客戶機連接到一個IEEE1394網絡時，會采用下列規則。
“htype”(硬件地址類型)必須是24[ARPPARAM]。
“hlen”(硬件地址長度)必須是0。
“chaddr”(客戶機硬件地址)字段保留。發送端必須把該字段設置為0，接收端和中繼
代理必須忽略它收到的值。
1394上的一臺DHCP客戶機應該在DHCPDISCOVER和DHCPREQUEST消息中設
置一個廣播標記(并且設置“ciaddr”為0)來保證服務器(或中繼代理)把它的應答廣播給客戶
機。
注重：正如在[RFC2131]中描述的那樣，在跳躍、更新或重裝狀態下，“ciaddr”必須用
客戶機的IP地址添滿，所以，不應當設置廣播標記。在這些案例中，DHCP服務器向“ciaddr”
中的地址單播DHCPACK消息。鏈路地址將由1394ARP決定。
由于缺少“chaddr”，從客戶機到服務器，在DHCP消息中必須使用“clientidentifier”
選項?！癱lientidentifier”選項可以由任何數據組成。因為每個1394節點上的IP有一個EUI-64
(節點獨有ID)，EUI-64構成了明確的“clientidentifier”。1394客戶機應該在“clientidentifier”
選項中包括一個EUI-64標識符。EUI-64類型值為27[ARPPARAM]，舉例說明格式如下。
1
2
3
4
5
6
7
8
9
10
11
Code
Len
Type
Client-Identifier
61
9
27
EUI-64(nodeuniqueID)
注重本備忘錄不排除其他“clientidentifier”類型的用法，就象正式域名(fullyqualified
domainname，縮寫為FQDN)那樣的。
細節詳見[RFC2132]中的“9.14.Client-identifier”。
4.安全因素
目前，DHCP不提供認證或安全機制。在DHCP協議規范[RFC2131]的第7節中討論了
可能引起攻擊的潛在漏洞。
惡意的客戶機可能偽造它的EUI-64標識符，來偽裝成其他的客戶機。
致謝
作者對DynamicHostConfiguration工作組成員的校訂工作和寶貴意見表示感謝。
參考文獻
[RFC2734]Johansson,P.,"IPv4overIEEE1394",RFC2734,December1999.
[RFC2119]Bradner,S.,"KeyWordsforuseinRFCstoIndicateRequirementLevels",
RFC2119,March1997.
[RFC2131]Droms,R.,"DynamicHostConfigurationProtocol",RFC2131,March
1997.
[RFC2132]Extensions",RFC2132,March1997.
[ARPPARAM]http://www.iana.org/numbers.Html
作者地址：
KenjiFujisawa
SonyCorporation
6-7-35,Kitashinagawa,
Shinagawa-ku,Tokyo,141-0001Japan

Phone:+81-3-5448-8507
EMail:fujisawa@sm.sony.co.jp
完整的版權聲明
Copyright(C)TheInternetSociety(2000)。版權所有。
Thisdocumentandtranslationsofitmaybecopiedandfurnishedtoothers,and
derivativeworksthatcommentonorotherwiseeXPlainitorassistinitsimplementation
maybeprepared,copied,publishedanddistributed,inwholeorinpart,withoutrestriction
ofanykind,providedthattheabovecopyrightnoticeandthisparagraphareincludedonall
sUChcopiesandderivativeworks.However,thisdocumentitselfmaynotbemodifiedin
anyway,suchasbyremovingthecopyrightnoticeorreferencestotheInternetSocietyor
otherInternetorganizations,exceptasneededforthepurpoSEOfdevelopingInternet
standardsinwhichcasetheproceduresforcopyrightsdefinedintheInternetStandards
processmustbefollowed,orasrequiredtotranslateitintolanguagesotherthanEnglish.
Thelimitedpermissionsgrantedaboveareperpetualandwillnotberevokedbythe
InternetSocietyoritssuccessorsorassigns.
Thisdocumentandtheinformationcontainedhereinisprovidedonan"ASIS"basis
andTHEINTERNETSOCIETYANDTHEINTERNETENGINEERINGTASKFORCE
DISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDINGBUTNOT
LIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATIONHEREINWILL
NOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOFMERCHANTABILITY
ORFITNESSFORAPARTICULARPURPOSE.
致謝
目前，RFC編者活動的基金由Internet社團提供。