IPv6通過ATM網絡

備忘錄：
本文檔為整個因特網指定了一個標準跟蹤協議，并為其改進展提供了一些討論和建議。請參
考最新版的"Inte.net官方協議標準"(STD1)來獲得本協議的標準化程度和狀態。本備忘錄的
傳播不受任何限制。

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

摘要：
本文檔《Ipv6通過非廣播多通路（NBMA）網絡》是ION工作組的結構文檔之一。它提供
了怎樣應用Ipv6通過NBMA結構到異步傳輸模式（ATM）網絡的詳細資料。該結構允許常
規的Ipv6臨近計算機發現協議的主機-分機操作，同時也支持已建立的短程ATM傳送路徑
以及通過行政管理配置的點到點PVC的操作。

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

1.緒論
本文檔《Ipv6通過NBMA網絡》規范是ION工作組對ATM的詳細說明文檔。至于術語和
結構的描述這里將不再重復。

ATM可提供點到點的PVC服務，或者更加靈活的點到點和點到多點的SVC服務，本文檔
涵蓋了ATM的這些應用。

一個最低限度符合標準的Ipv6/ATM驅動應至少能支持PVC模式的操作。而一個Ipv6/ATM
驅動支持完全的SVC模式同時也將支持PVC模式的操作。

2.規范術語
本文檔中，"MUST","MUSTNOT","REQUIRED","SHALL","SHALLNOT","SHOULD",
"SHOULDNOT","RECOMMENDED","MAY",以及"OPTIONAL"等關鍵詞的含義請參閱
RFC2119文檔。

3.PVC環境
當ATM網絡用于PVC模式時，每一條PVC將精確的連接兩個節點且臨近計算機發現和其
他的Ipv6的特殊功能將受到限制。Ipv6/ATM接口在每一條鏈路上只有一個鄰居接口。既然
在一單一的ATM標準的操作中不能進行多點傳送和廣播操作，因而MARS和NHRP協議
不再必須。動態的發現的傳送捷徑不被支持。

接下來的章節提供關于封裝，MTU和鏈接令牌產生的詳細資料。

PVC鏈路的這種應用既不授權也不阻止在臨近計算機發現協議中擴展名的使用，這可由
PVC連接中的任一普通使用而發現。

既然ATM網絡中PVC鏈接不使用鏈路層的地址，那么任何的網絡指導消息中都不能包含
鏈路層的地址操作。一旦在某一網絡指導消息中出現鏈路層地址操作，那么該操作將被忽略。

一最低限度符合標準的Ipv6/ATM驅動將應至少能支持PVC模式操作。這種單一執行PVC
的結構并不要求支持任何的SVC模式操作。

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

3.2選擇性空封裝
Ipv6/ATM驅動有可能也支持空封裝作為一項可配置操作。當空封裝被激活，Ipv6數據直接
通過到ALL5層。PVC鏈路的兩端應同時配置使用空封裝。PVC不會被除Ipv6以外的其他
協議所用到。

3.3PPP封裝
本規范文檔不包含Ipv6通過PPP和PPP通過ALL5的虛擬電路的串聯。

3.4PVC環境下MTU
默認的PVC鏈路的IPMTU長度為9180字節。詳細說明參看[7]。其他的IPMTU值也可
能被應用。

3.5PVC環境下的接口令牌格式
當ATM網絡用于PVC模式時，接口令牌應當用第5節中所記述的方法產生。在PVC鏈路
的兩個節點之間接口令牌必須是唯一的。

4.SVC環境

4.1SVC特殊代碼點

4.1.1SVC環境下的ATM適配層封裝

下面可參考RFC1483原文。ALL5為默認的適配層服務協議，（LLC/SNAP）封裝為系統設
定的適用于通過SVC鏈路的單點傳送和多點傳送數據的封裝。

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

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

IPv6/ATM驅動的群體成員ID需要記錄在pkt$cmi段的2個8位字節優先傳送。

4.1.4選擇性空封裝
IPv6/ATM驅動也可能支持空封裝做為一項可配置操作?？辗庋b只能被用作從一個IPv6/ATM
驅動傳送IPv6包到另一個?？辗庋b不能被用在在IPv6/ATM驅動和當地MARS之間的點到
點SVC操作。

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

如果在路由器之間的數據SVC中有空封裝，則中間路由的NHRP通信必須利用一獨立平行
的SVC。

當IPv6/ATM和MARS/NHRP/ND一起使用時（參見[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段應為0x86DD（IPv6）

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

mar$spln和mar$tpln段為0（空消息）或16（全IPv6協議地址）

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段應為0x86DD（IPv6）

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

ar$spln和ar$tpln段為0（空消息）或16（全IPv6協議地址）

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

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

[NTL]定義ATM數值的類型和長度，緊接為[STL]字段。格式如下：
76543210
+-+-+-+-+-+-+-+-+
|0|x|length|
+-+-+-+-+-+-+-+-+

第一有效位保留并需至為零。第二有效位（x）是一個ATM數值是否在其中的標志：

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

末端的6位為一無符號整數指出8位字節段中關聯的ATM地址段的長度。

[STL]格式同[NTL]段。如果其存在，則定義子地址段的長度。如果其不存在則這個8位字
節段必須全為零。如果子地址存在則將為AESA格式，所以標記x應為零。

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

[NBMASubaddress]是一個包含面向鏈路層ATM子地址的變長字段。它可能存在，也可能
不存在。當它不存在的時候，選項于[NBMANumber]（或者其他為填滿8位隊列的附加字
節）之后結束。

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

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

注意：當[7]中的程序仍然應用到ATM上的IPv6時，節點和路由使用IPv6路徑MTU發現
[8]勝于IPv4MTU發現。另外，當IPv6節點不需要實現路徑MTU發現時，IPv6/ATM節點
將應實現它。所以，既然IPv6節點將為每一個VC協商一適當的MTU，當兩節點沒有接收
到過大的以至觸發路徑MTU發現的數據包時路徑MTU將不被觸發。當節點中的通訊通過
一個或多個路由時，路徑MTU發現將按傳統網絡的方法來使用。

5.接口令牌
對于無論PVC或是SVC模式操作，按[1]中5.1節所要求的必須使用下列方法產生接口令牌。

5.1基于ESI值的接口令牌
當潛在的ATM接口被ATM末端系統地址（AESA）識別出時，接口令牌可能由AESA中的
ESI和SEL值構成。如下：
[0x00][ESI][SEL]

[0x00]是一個總設為0的8位字段。
注意：這個和EUI-64的全局/局部標志位相應的位總是置0表明這不地址不是一全局唯
一的IPv6接口令牌。

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

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

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

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

當EUI-64值用于IPv6接口令牌，從NIC讀取的字節串中唯一允許改動為倒置全局/局部標
識位。

5.4基于當地E.164地址的接口令牌
當一接口應用當地E.164地址時，E.164值可用于產生接口令牌如下：
[D14][D13D12][D11D10][D9D8][D9D6][D5D4][D3D2][D1D0]

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

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

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

5.5無唯一標識符節點
如果接口令牌的產生中沒有用到MAC,EUI-64,AESA或E.164值，則接口令牌的產生必須按
照[10]中附錄A所述。

5.6單一接口的多邏輯鏈接
一個單一的ATM接口可能于一個普通AESA前綴中的不同SEL段相關聯，或者一組完全獨
立的ESI可能被當地ATM注冊用于交換建立特定AESA域。

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

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

6.結論和公開發行
本文檔《Ipv6通過NBMA網絡》規范是ION工作組對ATM的詳細說明文檔。它詳細說明
了定態配置PVC和動態制訂SVC操作模式的碼點。

Therearenomajoropenissues.CommentstotheIONmailinglistaresolicited(ion@nexen.com).

7.安全考慮
本提議不引入任何新的安全機制，故所有當前的IPv6安全機構的運行無需針對ATM加以修
正。這包含臨近計算機發現協議的確認和加密，如IPv6數據包的交換。

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

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

作者聯系方式：
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-BroadcastMultipleAclearcase/" target="_blank" >ccess(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.