本备忘录的状态
本文档讲述了一种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”
选项。“clientidentifier”选项可以由任何数据组成。因为每个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]Alexander,S.andR.Droms,"DHCPOptionsandBOOTPVendor
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社团提供。