備忘錄：
本文檔為整個(gè)因特網(wǎng)指定了一個(gè)標(biāo)準(zhǔn)跟蹤協(xié)議，并為其改進(jìn)展提供了一些討論和建議。請參
考最新版的"Internet官方協(xié)議標(biāo)準(zhǔn)"(STD1)來獲得本協(xié)議的標(biāo)準(zhǔn)化程度和狀態(tài)。本備忘錄的
傳播不受任何限制。

版權(quán)聲明：
Copyright(C)TheInternetSociety(1999).AllRightsReserved.

摘要：
本文檔《ipv6通過非廣播多通路（NBMA）網(wǎng)絡(luò)》是ION工作組的結(jié)構(gòu)文檔之一。它提供
了怎樣應(yīng)用Ipv6通過NBMA結(jié)構(gòu)到異步傳輸模式（ATM）網(wǎng)絡(luò)的具體資料。該結(jié)構(gòu)答應(yīng)常
規(guī)的Ipv6臨近計(jì)算機(jī)發(fā)現(xiàn)協(xié)議的主機(jī)-分機(jī)操作，同時(shí)也支持已建立的短程ATM傳送路徑
以及通過行政治理配置的點(diǎn)到點(diǎn)PVC的操作。

目錄
1.緒論 2
2.規(guī)范術(shù)語 3
3.PVC環(huán)境 3
3.1系統(tǒng)設(shè)定數(shù)據(jù)封裝格式 3
3.2選擇性空封裝 3
3.3PPP封裝 4
3.4PVC環(huán)境下MTU 4
3.5PVC環(huán)境下的接口令牌格式 4
4.SVC環(huán)境 4
4.1SVC非凡代碼點(diǎn) 4
4.1.1SVC環(huán)境下的ATM適配層封裝 4
4.1.2單點(diǎn)傳送數(shù)據(jù)封裝 4
4.1.3多點(diǎn)傳送數(shù)據(jù)封裝 5
4.1.4選擇性空封裝 5
4.1.5MARS控制信息 5
4.1.6NHRP控制信息 6
4.1.7臨近計(jì)算機(jī)協(xié)議消息 6
4.2UNI3.0/3.1信號發(fā)布（SVC模式） 7
5.接口令牌 7
5.1基于ESI值的接口令牌 7
5.2基于48位MAC值的接口令牌 8
5.3基于EUI-64值的接口令牌 8
5.4基于當(dāng)?shù)谽.164地址的接口令牌 8
5.5無唯一標(biāo)識符節(jié)點(diǎn) 8
5.6單一接口的多邏輯鏈接 8
6.結(jié)論和公開發(fā)行 9
7.安全考慮 9
感謝： 9
作者聯(lián)系方式： 9
參考書目： 10
FullCopyrightStatement 11

1.緒論
本文檔《Ipv6通過NBMA網(wǎng)絡(luò)》規(guī)范是ION工作組對ATM的具體說明文檔。至于術(shù)語和
結(jié)構(gòu)的描述這里將不再重復(fù)。

ATM可提供點(diǎn)到點(diǎn)的PVC服務(wù)，或者更加靈活的點(diǎn)到點(diǎn)和點(diǎn)到多點(diǎn)的SVC服務(wù)，本文檔
涵蓋了ATM的這些應(yīng)用。

一個(gè)最低限度符合標(biāo)準(zhǔn)的Ipv6/ATM驅(qū)動應(yīng)至少能支持PVC模式的操作。而一個(gè)Ipv6/ATM
驅(qū)動支持完全的SVC模式同時(shí)也將支持PVC模式的操作。

2.規(guī)范術(shù)語
本文檔中，"MUST","MUSTNOT","REQUIRED","SHALL","SHALLNOT","SHOULD",
"SHOULDNOT","RECOMMENDED","MAY",以及"OPTIONAL"等要害詞的含義請參閱
RFC2119文檔。

3.PVC環(huán)境
當(dāng)ATM網(wǎng)絡(luò)用于PVC模式時(shí)，每一條PVC將精確的連接兩個(gè)節(jié)點(diǎn)且臨近計(jì)算機(jī)發(fā)現(xiàn)和其
他的Ipv6的非凡功能將受到限制。Ipv6/ATM接口在每一條鏈路上只有一個(gè)鄰居接口。既然
在一單一的ATM標(biāo)準(zhǔn)的操作中不能進(jìn)行多點(diǎn)傳送和廣播操作，因而MARS和NHRP協(xié)議
不再必須。動態(tài)的發(fā)現(xiàn)的傳送捷徑不被支持。

接下來的章節(jié)提供關(guān)于封裝，MTU和鏈接令牌產(chǎn)生的具體資料。

PVC鏈路的這種應(yīng)用既不授權(quán)也不阻止在臨近計(jì)算機(jī)發(fā)現(xiàn)協(xié)議中擴(kuò)展名的使用，這可由
PVC連接中的任一普通使用而發(fā)現(xiàn)。

既然ATM網(wǎng)絡(luò)中PVC鏈接不使用鏈路層的地址，那么任何的網(wǎng)絡(luò)指導(dǎo)消息中都不能包含
鏈路層的地址操作。一旦在某一網(wǎng)絡(luò)指導(dǎo)消息中出現(xiàn)鏈路層地址操作，那么該操作將被忽略。

一最低限度符合標(biāo)準(zhǔn)的Ipv6/ATM驅(qū)動將應(yīng)至少能支持PVC模式操作。這種單一執(zhí)行PVC
的結(jié)構(gòu)并不要求支持任何的SVC模式操作。

3.1系統(tǒng)設(shè)定數(shù)據(jù)封裝格式
下面內(nèi)容可參考RFC1483文檔[2]，AAL5為默認(rèn)的適配層服務(wù)協(xié)議，（LLC/SNAP）封裝為
系統(tǒng)設(shè)定的適用于通過點(diǎn)到點(diǎn)的PVC鏈路的數(shù)據(jù)的封裝。如[1]中所定義，系統(tǒng)默認(rèn)的Ipv6
的數(shù)據(jù)封裝格式為：
[0xAA-AA-03][0x00-00-00][0x86-DD][IPv6packet]
(LLC)(OUI)(PID)

3.2選擇性空封裝
Ipv6/ATM驅(qū)動有可能也支持空封裝作為一項(xiàng)可配置操作。當(dāng)空封裝被激活，Ipv6數(shù)據(jù)直接
通過到ALL5層。PVC鏈路的兩端應(yīng)同時(shí)配置使用空封裝。PVC不會被除Ipv6以外的其他
協(xié)議所用到。

3.3PPP封裝
本規(guī)范文檔不包含Ipv6通過PPP和PPP通過ALL5的虛擬電路的串聯(lián)。

3.4PVC環(huán)境下MTU
默認(rèn)的PVC鏈路的IPMTU長度為9180字節(jié)。具體說明參看[7]。其他的IPMTU值也可
能被應(yīng)用。

3.5PVC環(huán)境下的接口令牌格式
當(dāng)ATM網(wǎng)絡(luò)用于PVC模式時(shí)，接口令牌應(yīng)當(dāng)用第5節(jié)中所記述的方法產(chǎn)生。在PVC鏈路
的兩個(gè)節(jié)點(diǎn)之間接口令牌必須是唯一的。

4.SVC環(huán)境

4.1SVC非凡代碼點(diǎn)

4.1.1SVC環(huán)境下的ATM適配層封裝

下面可參考RFC1483原文。ALL5為默認(rèn)的適配層服務(wù)協(xié)議，（LLC/SNAP）封裝為系統(tǒng)設(shè)
定的適用于通過SVC鏈路的單點(diǎn)傳送和多點(diǎn)傳送數(shù)據(jù)的封裝。

4.1.2單點(diǎn)傳送數(shù)據(jù)封裝
如[1]中所定義，默認(rèn)的Ipv6單點(diǎn)傳送數(shù)據(jù)封裝為：
[0xAA-AA-03][0x00-00-00][0x86-DD][IPv6packet]
(LLC)(OUI)(PID)

4.1.3多點(diǎn)傳送數(shù)據(jù)封裝
如[1]中所定義，默認(rèn)的Ipv6多點(diǎn)傳送數(shù)據(jù)封裝為：
[0xAA-AA-03][0x00-00-5E][0x00-01][pkt$cmi][0x86DD][IPv6packet]
(LLC)(OUI)(PID)(marsencaps)

IPv6/ATM驅(qū)動的群體成員ID需要記錄在pkt$cmi段的2個(gè)8位字節(jié)優(yōu)先傳送。

4.1.4選擇性空封裝
IPv6/ATM驅(qū)動也可能支持空封裝做為一項(xiàng)可配置操作。空封裝只能被用作從一個(gè)IPv6/ATM
驅(qū)動傳送IPv6包到另一個(gè)。空封裝不能被用在在IPv6/ATM驅(qū)動和當(dāng)?shù)豈ARS之間的點(diǎn)到
點(diǎn)SVC操作。

假如空封裝被激活，IPv6包直接被傳送到AAL5層。在呼叫建立階段，SVC的兩端口必須
同意使用空封裝。使用IPv6以外的協(xié)議SVC將不可利用。

假如在路由器之間的數(shù)據(jù)SVC中有空封裝，則中間路由的NHRP通信必須利用一獨(dú)立平行
的SVC。

當(dāng)IPv6/ATM和MARS/NHRP/ND一起使用時(shí)（參見[1]），不鼓勵使用空封裝。

4.1.5MARS控制信息
MARS控制信息（在MARS和MARS客戶端之間）的封裝如RFC2022[3]中所示：
[0xAA-AA-03][0x00-00-5E][0x00-03][MARScontrolmessage]
(LLC)(OUI)(PID)

要害控制字段值如下：

mar$afn段保持為0x0F（ATM地址）

mar$PRo段應(yīng)為0x86DD（IPv6）

mar$op.version段保持為0x00（MARS）

mar$spln和mar$tpln段為0（空消息）或16（全I(xiàn)Pv6協(xié)議地址）

ATM地址如何保存沿用了RFC2022[3]中的方法。

4.1.6NHRP控制信息
NHRP控制信息的封裝如RFC2332[4]：
[0xAA-AA-03][0x00-00-5E][0x00-03][NHRPcontrolmessage]
(LLC)(OUI)(PID)

要害字段的值如下：

ar$afn段保持0x0F（ATM地址）

ar$pro段應(yīng)為0x86DD（IPv6）

ar$op.version段保持0x01（NHRP）

ar$spln和ar$tpln段為0（空消息）或16（全I(xiàn)Pv6協(xié)議地址）

ATM地址如何保存沿用了RFC2022[3]中的方法。

4.1.7臨近計(jì)算機(jī)協(xié)議消息
[1]中5.2節(jié)描述了ND鏈路層地址選項(xiàng)。對于IPv6/ATM驅(qū)動，子字段需按如下方法編碼：

[NTL]定義ATM數(shù)值的類型和長度，緊接為[STL]字段。格式如下：
76543210
+-+-+-+-+-+-+-+-+
0xlength
+-+-+-+-+-+-+-+-+

第一有效位保留并需至為零。第二有效位（x）是一個(gè)ATM數(shù)值是否在其中的標(biāo)志：

ATM論壇AESA格式（x=0）.
本地的E.164格式（x=1）.

末端的6位為一無符號整數(shù)指出8位字節(jié)段中關(guān)聯(lián)的ATM地址段的長度。

[STL]格式同[NTL]段。假如其存在，則定義子地址段的長度。假如其不存在則這個(gè)8位字
節(jié)段必須全為零。假如子地址存在則將為AESA格式，所以標(biāo)記x應(yīng)為零。

[NBMANumber]是一個(gè)包含面向鏈路層ATM地址的變長字段。它總是存在的。

[NBMASubaddress]是一個(gè)包含面向鏈路層ATM子地址的變長字段。它可能存在，也可能
不存在。當(dāng)它不存在的時(shí)候，選項(xiàng)于[NBMANumber]（或者其他為填滿8位隊(duì)列的附加字
節(jié)）之后結(jié)束。

[NBMANumber]段和[NBMASubaddress]段中8位字節(jié)的順序于它們用在MARS和NHRP
控制消息中時(shí)相同。

4.2UNI3.0/3.1信號發(fā)布（SVC模式）
當(dāng)一個(gè)IPv6節(jié)點(diǎn)向另一個(gè)IPv6節(jié)點(diǎn)發(fā)出一條呼叫，必須遵循[6][7]中的程序。如[7]中所記
述，默認(rèn)的LL算法上的IPMTU長度為9180字節(jié)。

注重：當(dāng)[7]中的程序仍然應(yīng)用到ATM上的IPv6時(shí)，節(jié)點(diǎn)和路由使用IPv6路徑MTU發(fā)現(xiàn)
[8]勝于IPv4MTU發(fā)現(xiàn)。另外，當(dāng)IPv6節(jié)點(diǎn)不需要實(shí)現(xiàn)路徑MTU發(fā)現(xiàn)時(shí)，IPv6/ATM節(jié)點(diǎn)
將應(yīng)實(shí)現(xiàn)它。所以，既然IPv6節(jié)點(diǎn)將為每一個(gè)VC協(xié)商一適當(dāng)?shù)腗TU，當(dāng)兩節(jié)點(diǎn)沒有接收
到過大的以至觸發(fā)路徑MTU發(fā)現(xiàn)的數(shù)據(jù)包時(shí)路徑MTU將不被觸發(fā)。當(dāng)節(jié)點(diǎn)中的通訊通過
一個(gè)或多個(gè)路由時(shí)，路徑MTU發(fā)現(xiàn)將按傳統(tǒng)網(wǎng)絡(luò)的方法來使用。

5.接口令牌
對于無論P(yáng)VC或是SVC模式操作，按[1]中5.1節(jié)所要求的必須使用下列方法產(chǎn)生接口令牌。

5.1基于ESI值的接口令牌
當(dāng)潛在的ATM接口被ATM末端系統(tǒng)地址（AESA）識別出時(shí)，接口令牌可能由AESA中的
ESI和SEL值構(gòu)成。如下：
[0x00][ESI][SEL]

[0x00]是一個(gè)總設(shè)為0的8位字段。
注重：這個(gè)和EUI-64的全局/局部標(biāo)志位相應(yīng)的位總是置0表明這不地址不是一全局唯
一的IPv6接口令牌。

[ESI]是一6個(gè)8位字節(jié)字段。
該段總包含6個(gè)8位字節(jié)的ESI值，AESA以此尋IPv6/ATM的接口地址。

[SEL]為一個(gè)8位字節(jié)
該段總包含6個(gè)8位字節(jié)的SEL值，AESA以此尋IPv6/ATM的接口地址。

5.2基于48位MAC值的接口令牌
當(dāng)潛在的ATMNIC驅(qū)動已讀取一或多ATMNIC特有的48位MAC值，IPv6/ATM接口可
應(yīng)用這些值建立一特定的接口令牌，如[10]中所述。

5.3基于EUI-64值的接口令牌
當(dāng)潛在的ATMNIC驅(qū)動已讀取一或多ATMNIC特有的64位EUI-64值，IPv6/ATM接口可
應(yīng)用這些值，反置全局/局部標(biāo)識符，建立一特定的接口令牌。

當(dāng)EUI-64值用于IPv6接口令牌，從NIC讀取的字節(jié)串中唯一答應(yīng)改動為倒置全局/局部標(biāo)
識位。

5.4基于當(dāng)?shù)谽.164地址的接口令牌
當(dāng)一接口應(yīng)用當(dāng)?shù)谽.164地址時(shí)，E.164值可用于產(chǎn)生接口令牌如下：
[D14][D13D12][D11D10][D9D8][D9D6][D5D4][D3D2][D1D0]

[D14]：一單一的8位字節(jié)包含半8位字節(jié)表示最重要的E.164數(shù)位左移4位到8位字節(jié)中
最重要的4位。低四位必須置0。注重EUI-64全局/局部標(biāo)識符置0表示這是一個(gè)全局特定
IPv6接口令牌。

[D13D12]：一單一的8位字節(jié)包含半8位字節(jié)表示次重要的E.164數(shù)位[D13]左移4位到8
位字節(jié)中最重要的4位，第三重要的半8字節(jié)在8位字節(jié)中最次要的4位中。

[D11D10]-[D1D0]：每一個(gè)均包含兩個(gè)E.164數(shù)位的8位字節(jié)組，兩個(gè)E.164數(shù)位中，其一
在最重要的4位字節(jié)中，另一在最次要的4位字節(jié)中。

5.5無唯一標(biāo)識符節(jié)點(diǎn)
假如接口令牌的產(chǎn)生中沒有用到MAC,EUI-64,AESA或E.164值，則接口令牌的產(chǎn)生必須按
照[10]中附錄A所述。

5.6單一接口的多邏輯鏈接
一個(gè)單一的ATM接口可能于一個(gè)普通AESA前綴中的不同SEL段相關(guān)聯(lián)，或者一組完全獨(dú)
立的ESI可能被當(dāng)?shù)谹TM注冊用于交換建立特定AESA域。

識別每一個(gè)邏輯ATM接口至少須知它們的ESI+SEL組合。

如[1]中5.1.2節(jié)對虛擬主機(jī)的描述，虛擬主機(jī)需要從64位數(shù)值隊(duì)列中選擇一個(gè)可應(yīng)用到ATM
NIC的不同的接口令牌。每一臺虛擬主機(jī)必須實(shí)現(xiàn)IPv6/ATM接口按下面的方式：不可存在
兩臺或兩臺以上的虛擬主機(jī)向同一LL終止通告同一接口令牌。（為了順應(yīng)這一要求，可選
擇不同的SEL值或（和）ESI值。）

6.結(jié)論和公開發(fā)行
本文檔《Ipv6通過NBMA網(wǎng)絡(luò)》規(guī)范是ION工作組對ATM的具體說明文檔。它具體說明
了定態(tài)配置PVC和動態(tài)制訂SVC操作模式的碼點(diǎn)。

Therearenomajoropenissues.CommentstotheIONmailinglistaresolicited(ion@nexen.com).

7.安全考慮
本提議不引入任何新的安全機(jī)制，故所有當(dāng)前的IPv6安全機(jī)構(gòu)的運(yùn)行無需針對ATM加以修
正。這包含臨近計(jì)算機(jī)發(fā)現(xiàn)協(xié)議的確認(rèn)和加密，如IPv6數(shù)據(jù)包的交換。

感謝：
最初的IPv6/ATM著作由G.Armitage在受雇于Bellcore期間完成。第四節(jié)借鑒了MAtt
Crawford的備忘錄《IPv6通過以太網(wǎng)》。

這里作者要對KazuhikoYamamoto,KenjiroCho,YoshinobuInoue,HiroshiEsaki,Yoshifumi
Atarashi,AtsushiHagiwara等對實(shí)際PVC實(shí)現(xiàn)所做出的貢獻(xiàn)表示感謝。

作者聯(lián)系方式：
GrenvilleArmitage
BellLaboratories,LUCentTechnologies
101CrawfordsCornerRoad
Holmdel,NJ07733
USA

EMail:gja@lucent.com


PeterSchulter
BrightTigerTechnologies
125NagogPark
Acton,MA01720

EMail:paschulter@acm.org


MarkusJork
EuropeanAppliedResearchCenter
DigitalEquipmentGmbH
CECKarlsruhe
Vincenz-Priessnitz-Str.1
D-76131Karlsruhe
Germany

EMail:jork@kar.dec.com

參考書目：
[1]Armitage,G.,Schulter,P.,Jork,M.andG.Harter,"IPv6over
Non-BroadcastMultipleaccess(NBMA)networks",RFC2491,January
1999.

[2]Heinanen,J.,"MultiprotocolEncapsulationoverATMAdaption
Layer5",RFC1483,July1993.

[3]Armitage,G.,"SupportforMulticastoverUNI3.1basedATM
Networks",RFC2022,November1996.

[4]Luciani,J.,Katz,D.,Piscitello,D.,Cole,B.andN.Doraswamy,
"NBMANextHopResolutionProtocol(NHRP)",RFC2332,April1998.

[5]"64-BitGlobalIdentifierFormatTutorial",
http://standards.ieee.org/db/oui/tutorials/EUI64.Html.

[6]Perez,M.,Liaw,F.,Mankin,A.,Hoffman,E.,Grossman,D.andA.
Malis,"ATMSignallingSupportforIPoverATM",RFC1755,
February1995.

[7]Atkinson,R.,"DefaultIPMTUforuSEOverATMAAL5",RFC1626,
May1994.

[8]McCann,J.,Deering,S.andJ.Mogul,"PathMTUDiscoveryforIP
version6",RFC1981,August1996.

[9]ATMForum,"ATMUserNetworkInterface(UNI)Specification
Version3.1",ISBN0-13-393828-X,PrenticeHall,Englewood
Cliffs,NJ,June1995.

[10]Hinden,B.andS.Deering,"IPVersion6Addressing
Architecture",RFC2373,July1998.

[11]Narten,T.,Nordmark,E.andW.Simpson,"NeighborDiscoveryfor
IPVersion6(IPv6)",RFC2461,December1998.

FullCopyrightStatement

Copyright(C)TheInternetSociety(1999).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseeXPlainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.