🥜
RFC 5549: IPv6ネクストホップによるIPv4ネットワーク層の到達性情報の広告

2024/10/25に公開
RFC
bgp
IPv6
tech
 本文書の位置付け本文書は、インターネット・コミュニティのためのインターネット標準トラック・プロトコルを規定し、改善のための議論と提案を求める。このプロトコルの標準化状況とステータスについては、最新版の「インターネット公式プロトコル標準」(STD 1)を参照のこと。このメモの配布は無制限である。

 著作権表示Copyright (c) 2012 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。
本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。

 概要マルチプロトコルBGP(MP-BGP)は、ネクストホップ・フィールドで伝送されるアドレスが属するネットワーク層プロトコルを、アドレス・ファミリー識別子(AFI)と後続アドレス・ファミリー識別子(SAFI)によって決定することを規定している。IPv4アドレス・ファミリーの現在のAFI/SAFI定義には、IPv4ネットワーク層到達性情報(NLRI)またはVPN-IPv4 NLRIを広告するときに、IPv4プロトコルに属するネクストホップ・アドレスを広告するための規定のみがある。本文書は、 IPv4 NLRIやVPN-IPv4 NLRIをIPv6プロトコルに属するネクストホップ・アドレスで広告できるようにするために必要な拡張を規定する。この仕様は、IPv4 NLRIやVPN-IPv4 NLRIのネクストホップのアドレスがIPv6プロトコルにも属することを可能にするためのAFI/SAFI定義の拡張、アドレスが実際にどのプロトコルに属するかを判断するためのネクストホップのエンコーディング、およびMP-BGPピアがIPv6ネクストホップおよびIPv4 NLRIとVPN-IPv4 NLRIを交換できるかどうかを動的に検出するための新しいBGP機能からなる。

 1. はじめにマルチプロトコルBGP(MP-BGP)[RFC4760]では、ネクストホップ・フィールドで伝送されるアドレスが属する可能性のあるネットワーク層プロトコルは、アドレス・ファミリー識別子 (AFI)と後続アドレス・ファミリー識別子(SAFI)によって決定されると規定されている。既存の多くのAFI/SAFIでは、ネクストホップ・アドレスがネットワーク層到達性情報(NLRI)とは異なるアドレス・ファミリーに属することが可能である。例えば、L2VPNの自動検出を行うために使われるAFI/SAFI <25/65> ([L2VPN-SIG]による)は、ネクストホップ・フィールドにPEのループバック・アドレスが含まれる一方で、仮想プライベートLANサービス(VPLS)インスタンスの識別子を含むNLRIまたは特定のプロバイダ・エッジ(PE)の接続回線プールを識別するNLRIを広告することができる。同様に、経路ターゲット(RT)メンバーシップ情報を広告するためのAFI/SAFI <1/132> ([RFC4684]で定義)を使用すると、そのようなRTメンバーシップ情報を含むNLRIを広告できるが、ネクストホップ・フィールドには広告ルータのアドレスが含まれる。
さらに、これらの既存のAFI/SAFIの多くは、ネクストホップがIPv4ネットワーク層プロトコルまたはIPv6ネットワーク層プロトコルのいずれかに属することを許可し、アドレスが実際にどちらのプロトコルに属するかを判断するために、ネクストホップ情報のエンコーディングを指定する。例えば、[RFC4684]では、ネクストホップ・アドレスはIPv4またはIPv6のいずれであることを許可しており、ネクストホップ・アドレスの長さが4オクテットの場合はIPv4アドレスとして解釈し、ネクストホップ・アドレスの長さが16オクテットの場合はIPv6アドレスとして解釈すると規定している。
[RFC4925]や[MESH-FMWK]で説明されているような状況では、キャリア(または、内部リソース用にキャリアとして機能する大規模な企業ネットワーク)が、異なるアドレス・ファミリー・タイプのトランジット・コアを越えて、あるアドレス・ファミリー・タイプのネットワークの「島々」間の接続を確立することが求められる場合がある。これには、IPv4コアを跨ぐIPv6島の場合と、IPv6コアを跨ぐIPv4島の場合の両方が含まれる。対応する到達性情報を広告するためにマルチプロトコルBGP(MP-BGP)を使用する場合、これは、異なるのアドレス・ファミリーのネクストホップ(つまり、IPv4ネクストホップを使用した IPv6 NLRIとIPv6ネクストホップを使用したIPv4 NLRI)を介して、指定のアドレス・ファミリーのネットワーク層到達性情報(NLRI)を広告するBGPスピーカの要件を意味する。
IPv6アドレス・ファミリーに関する現在のAFI/SAFIの定義では、ネクストホップ・アドレスがIPv6アドレス・ファミリー・タイプに属することを前提としている。具体的には、[RFC2545]および[RFC3107]に従い、<AFI/SAFI>が<2/1>、<2/2>、または<2/4>の場合、ネクストホップ・アドレスはIPv6タイプであると想定される。[RFC4659]に従い、<AFI/SAFI>が<2/128>の場合、ネクストホップ・アドレスはIPv6-VPNタイプであると想定される。
⚠️ ここで出てくるAFI/SAFIAFI


番号
説明
リファレンス


1
IP (IPバージョン4)


2
IP (IPバージョン6)


25
L2VPN情報のためのAFI
[RFC4761] [RFC6074]

SAFI


値
説明
リファレンス


1
ユニキャスト・フォワーディングに使われるネットワーク層到達性情報
[RFC4760]

2
マルチキャスト・フォワーディングに使われるネットワーク層到達性情報
[RFC4760]

4
MPLSラベル付きネットワーク層到達性情報
[RFC8277]

65
仮想プライベートLANサービス(VPLS)
[RFC4761] [RFC6074]

128
MPLSラベル付きVPNアドレス
[RFC4364] [RFC8277] [RFC9252]

132
経路ターゲットの制約
[RFC4684]

しかし、[RFC4798]および[RFC4659]では、IPv6 NLRIをIPv4ネクストホップで広告する必要がある場合、ネクストホップのIPv6アドレス・フィールド内にIPv4アドレスをエンコードする方法を規定している。[RFC4798]では、<AFI/SAFI>が<2/1>、<2/2>、または<2/4>の場合に、IPv6アドレス・アーキテクチャ([RFC4291])で規定されているIPv4射影IPv6アドレス(IPv4-mapped IPv6 address)形式をその目的で使用することを定義している。[RFC4659]では、<AFI/SAFI>が<2/128>の場合に、IPv4射影IPv6アドレス形式とルート識別子のnull値をその目的で使用することを定義している。したがって、IPv4ネクストホップを使用したIPv6 NLRIの広告に対する既存のソリューションが存在する。
同様に、IPv4 NLRIまたはVPN-IPv4 NLRIの広告に関する現行のAFI/SAFI定義は、ネクストホップ・アドレスがIPv4アドレス・ファミリー・タイプに属することを前提としている。具体的には、[RFC4760]および[RFC3107]に従って、<AFI/SAFI>が<1/1>、<1/2>、<1/4>の場合、ネクストホップ・アドレスはIPv4タイプであると想定している。[RFC4364]によれば、<AFI/SAFI>が <1/128>の場合、ネクストホップ・アドレスはVPN-IPv4タイプであると想定している。ネクストホップのIPv4アドレス・フィールド内にIPv6アドレスをエンコードするための一般的に適用可能な方法は明らかに存在しない。したがって、現在、IPv4またはVPN-IPv4 NLRIをIPv6ネクストホップで広告するための規定されたソリューションは存在しない。
本文書は、そのために必要な拡張を規定する。この規定は、IPv4 NLRIまたはVPN-IPv4 NLRIのネクストホップのアドレスがIPv4またはIPv6プロトコルのいずれかに属することを許容するためのAFI/SAFI定義の拡張、アドレスが実際にどのプロトコルに属するかを判断するためのネクストホップ情報のエンコーディング、MP-BGPピアがIPv4 NLRIおよびVPN-IPv4 NLRIをIPv6ネクストホップと交換できるかどうかを動的に検出できるようにする新しいBGP機能からなる。新しいBGP機能により、IPv6ネクストホップ経由でIPv4の到達性を広告する新機能を、フラグデイやトラフィックのブラックホール化のリスクなしに、段階的に導入することができる。

 2. 要件言語本文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、RFC 2119 [RFC2119]の記述にしたがって解釈される。

 3. IPv4アドレス・ファミリーのAFI/SAFI定義の拡張前述したように、MP-BGPは、ネクストホップ・フィールドで伝送されるアドレスが属する可能性のあるネットワーク層プロトコルを、アドレス・ファミリー識別子(AFI)と後続アドレス・ファミリー識別子(SAFI)によって判断することを規定している。現在の IPv4 NLRIまたはVPN-IPv4 NLRI のAFI/SAFI 定義(<1/1>、<1/2>、<1/4>、<1/128>)は、IPv4プロトコルに属するネクストホップ・アドレスを広告する規定のみが存在する。本文書は、IPv4 NLRIおよびVPN-IPv4 NLRIの広告に関するAFI/SAFIの定義を拡張して、ネクストホップ・アドレスが属することができるネットワーク層プロトコル・セットを拡張し、IPv4に加えてIPv6も含める。
具体的には、この文書では、以下の条件でMP_REACH_NLRI [RFC4760]による広告を許可する:
AFI = 1
SAFI = 1、2、4、128
ネクストホップ・アドレスの長さ = 16または32
ネクストホップ・アドレス = ネクストホップのIPv6アドレス (ネクストホップのリンク・ローカルIPv6アドレスが続く可能性がある)。このフィールドは、[RFC2545] のセクション3に従って構築される。
NLRI = 現在のAFI/SAFI定義に従ったNLRI
これは、現在の動作モードに加えて、IPv4タイプのネクストホップ・アドレスを持つ<1/1>、<1/2>、<1/4>の<AFI/SAFI>のNLRIの広告と、VPN-IPv4タイプのネクストホップ・アドレスを持つ<1/128>の<AFI/SAFI>のNLRIの広告を許可する。
広告を受信するBGPスピーカは、ネクストホップ・アドレスがどのネットワーク層プロトコルに属するかを判断するために、ネクストホップ・アドレスの長さフィールドを使用しなければならない(MUST)。ネクストホップ・アドレス・フィールドの長さが16または32の場合、ネクストホップ・アドレスのタイプはIPv6である。
ネクストホップ・アドレス・フィールドの長さを使用して、ネクストホップ・アドレスがどのネットワーク層プロトコル(AFI/SAFI定義で許可されているプロトコルのうち)に属するかを判断する方法は、[RFC4684]および[L2VPN-SIG]で使用されている方法と同じであることに留意すること。

 4. BGPケイパビリティ広告の使用[RFC5492]は、2つのBGPスピーカは特定のケイパビリティをBGPピアがサポートしているかどうか、およびそのピアで使用できるかどうかを検出できるようにするメカニズムを定義している。本文書では、[RFC5492]を使用して広告できる新しいケイパビリティを定義し、それを拡張ネクストホップ・エンコーディング・ケイパビリティと呼ぶ。このケイパビリティにより、BGPスピーカは、特定のNLRI <AFI/SAFI>に対して、セクション3で規定されているように、ネットワーク・プロトコルがネクストホップ・アドレスの長さフィールドの値によって決定されるネクストホップでの広告をピアがサポートしているかどうかを検出することができる。
この仕様に従って、IPv4 NLRIまたはVPN-IPv4 NLRIのIPv6ネクストホップをBGPピアに広告したいBGPスピーカは、[RFC5492]で定義されているケイパビリティ広告手順を拡張ネクストホップ・エンコーディング・ケイパビリティと一緒に使用して、ピアが対象のNLRI AFI/SAFIペアでこれをサポートしているかどうかを確認しなければならない(MUST)。ケイパビリティ・オプション・パラメータのフィールドは以下のように設定しなければならない(MUST)。
ケイパビリティ・コード・フィールドは5(拡張ネクストホップ・エンコーディング・ケイパビリティを示す)に設定しなければならない(MUST)。
ケイパビリティ長さフィールドは、ケイパビリティ値フィールド(以下に続く)の長さである可変値に設定される。
ケイパビリティ値フィールドの形式は以下のとおりである:
ここで:
<NLRI AFI、NLRI SAFI、Nexthop AFI>の各トリプルNexthop AFIのネットワーク層プロトコルに属するネクストホップ・アドレスで、<NLRI AFI / NLRI SAFI>のNLRIを広告できることを示す。
AFIとSAFIの値は、IANAが管理するアドレス・ファミリー識別子と後続アドレス・ファミリー識別子のレジストリで定義する。
本文書はIPv6ネクストホップを使用したIPv4 NLRIおよびVPN-IPv4 NLRIの広告のみを対象としているため、本仕様では拡張ネクストホップ・エンコーディング・ケイパビリティのケーパビリティ値フィールドに以下の値のみを許可する:
NLRI AFI = 1 (IPv4)
NLRI SAFI = 1、2、4、128
Nexthop AFI = 2 (IPv6)
本仕様は、拡張ネクストホップ・エンコーディング・ケイパビリティを、他のどのような組み合わせの<NLRI AFI、NLRI SAFI、Nexthop AFI>でも使用できることを提案していない。特に、本仕様は、定義が既にIPv4とIPv6の両ネクストホップの使用を許可しているNLRI AFI/SAFI (例: [RFC4684]で定義されているAFI/SAFI = <1/132>)に対して拡張ネクストホップ・エンコーディング・ケイパビリティを使用することを提案していない。同様に、拡張ネクストホップ・エンコーディング・ケイパビリティを、異なるアドレス・ファミリーのネクストホップを広告するソリューションが既に存在するNLRI AFI/SAFIに使用することを提案していない(例: [RFC4798]にあるように、IPv4ネクストホップを持つAFI/SAFI = <2/1>、<2/2>、または <2/4>、および[RFC4659]にあるように、IPv4ネクストホップを持つAFI/SAFI = <2/128>)。
将来、新しいAFI/SAFIが定義される場合、その定義には最初から IPv4とIPv6の両方のネクストホップに対する規定(適切な場合)が設けられ、ネクストホップ・アドレス・フィールドの長さに基づいて判断されることが予想される。そのため、新しいAFI/SAFIでは拡張ネクストホップ・エンコーディング・ケイパビリティを使用しない。
BGPスピーカは、BGPピアが関連するAFI/SAFIペアの拡張ネクストホップ・エンコーディング・ケイパビリティをサポートしていることを、BGPケイパビリティ広告経由で最初に確認した場合にのみ、IPv6ネクストホップを含むIPv4またはVPN-IPv4 NLRIをBGPピアに広告しなければならない(MUST)。
拡張ネクストホップ・エンコーディング・ケイパビリティは、AFI/SAFIが許可されている場合に、指定されたAFI/SAFIのネクストホップ・エンコーディングに関する情報を提供する。そのAFI/SAFIが実際に許可されているかどうかには影響しない。BGPピア間でAFI/SAFIを使用できるかどうかは、[RFC4760]で定義されているマルチプロトコル拡張ケイパビリティによってのみ決定される。
拡張ネクストホップ・エンコーディング・ケイパビリティは、[DYN-CAP]で定義されている動的ケイパビリティと関連メカニズムを使用することで、動的に更新される可能性がある(MAY)。

 5. 運用デフォルトでは、特定のBGPセッションがIPvx (IPvxとはIPv4またはIPv6)上で実行されており、アップデートを送信するBGPスピーカが自身のアドレスをネクストホップとして入力する場合、更新されるNLRIのAFI/SAFI定義で指定されているエンコーディング・ルールを使用して、ネクストホップ・アドレスをIPvxアドレスとして指定する必要がある(SHOULD)。このデフォルトの動作は、ポリシーによって上書きすることができる。
ネクストホップ・アドレスを変更せずに渡す必要がある場合(例えば、ルート・リフレクタ(RR)が行うように)、そのエンコーディングを変更してはならない。RRクライアントがそのエンコーディングを処理できない場合(BGPケイパビリティ広告によって決定される)、問題のNLRIはそのクライアントに配布できない。あるシナリオで適切なルーティングを行うには、すべてのRRクライアントが、いずれかが生成するエンコーディングであっても処理できる必要がある。

 6. 使用例
 6.1. IPv4 over IPv6コア本文書で定義している拡張は、[MESH-FMWK]で説明しているように、IPv6バックボーン上のIPv4島の相互接続に使用することができる。このアプリケーションでは、アドレス・ファミリー境界ルータ(AFBR; [RFC4925]で定義)が、MP_REACH_NLRIでIPv4 NLRIをIPv6ネクストホップとともに広告する。
MP_REACH_NLRIは以下のようにエンコードされる:
AFI = 1
SAFI = 1
ネクストホップのネットワーク・アドレスの長さ = 16 (または32)
ネクストホップのネットワーク・アドレス = ネクストホップのIPv6アドレス
NLRI = IPv4経路
BGPケイパビリティ広告に、PEルータはケイパビリティ・オプション・パラメータに以下のフィールドを含める:
ケイパビリティ・コードを「拡張ネクストホップ・エンコーディング」に設定
ケイパビリティ値に<NLRI AFI=1, NLRI SAFI=1, Nexthop AFI=2>を含む

 6.2. IPv6コア経由の IPv4 VPN本文書で定義されている拡張は、IPv6バックボーン上のIPV4 VPNのサポートに使用できる。このアプリケーションでは、PEルータは、IPv6ネクストホップとともに、MP_REACH_NLRI でVPN-IPv4 NLRIを広告する。
MP_REACH_NLRIは以下のようにエンコードされる:
AFI = 1
SAFI = 128
ネクストホップ・ネットワーク・アドレスの長さ = 16 (または32)
ネクストホップのネットワーク・アドレス = ネクストホップのIPv6アドレス
NLRI = IPv4-VPN経路
BGPケイパビリティ広告中、PEルータはケイパビリティ・オプション・パラメータに以下のフィールドを含める:
ケイパビリティ・コードが「拡張ネクストホップ・エンコーディング」に設定されている
ケイパビリティ値に<NLRI AFI=1, NLRI SAFI=128, Nexthop AFI=2>が含まれている
⚠️ Ciscoによる例2台のCisco Nexusで、IPv6リンクローカルアドレスでBGPを張り、そこにIPv4経路を広告するサンプルで確認してみる。設定は下記の通り(対向はアドレスが異なるだけ)。
feature bgp
interface Ethernet1/1
  no switchport
  ip forward
  ipv6 address use-link-local-only
  no shutdown
interface loopback0
  ip address 10.0.0.1/32
router bgp 4200000000
  router-id 10.0.0.1
  log-neighbor-changes
  address-family ipv4 unicast
    network 100.1.0.0/16
    network 100.2.0.0/16
    network 100.3.0.0/16
    network 100.4.0.0/16
    network 100.100.0.0/16
    network 100.128.0.0/16
  neighbor Ethernet1/1
    remote-as external
    address-family ipv4 unicast
    address-family ipv6 unicast
BGP Openメッセージ(拡張ネクストホップ・エンコーディング・ケイパビリティ)
UPDATEメッセージ

経路の確認
nx2# show ip bgp summary 
BGP summary information for VRF default, address family IPv4 Unicast
BGP router identifier 10.1.0.1, local AS number 4200000100
BGP table version is 25, IPv4 Unicast config peers 1, capable peers 1
10 network entries and 10 paths using 2920 bytes of memory
BGP attribute entries [2/720], BGP AS path entries [1/6]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS    MsgRcvd    MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
fe80::ece:8cff:fe00:1b08%Ethernet1/1
                4 4200000000
                                27         26       25    0    0 00:09:21 6
nx2# show ip bgp 
BGP routing table information for VRF default, address family IPv4 Unicast
BGP table version is 25, Local Router ID is 10.1.0.1
Status: s-suppressed, x-deleted, S-stale, d-dampened, h-history, *-valid, >-best
Path type: i-internal, e-external, c-confed, l-local, a-aggregate, r-redist, I-injected
Origin codes: i - IGP, e - EGP, ? - incomplete, | - multipath, & - backup, 2 - best2

   Network            Next Hop            Metric     LocPrf     Weight Path
*>e100.1.0.0/16       fe80::ece:8cff:fe00:1b08
                                                                     0 4200000000 i
*>e100.2.0.0/16       fe80::ece:8cff:fe00:1b08
                                                                     0 4200000000 i
*>e100.3.0.0/16       fe80::ece:8cff:fe00:1b08
                                                                     0 4200000000 i
*>e100.4.0.0/16       fe80::ece:8cff:fe00:1b08
                                                                     0 4200000000 i
*>e100.100.0.0/16     fe80::ece:8cff:fe00:1b08
                                                                     0 4200000000 i
*>e100.128.0.0/16     fe80::ece:8cff:fe00:1b08
                                                                     0 4200000000 i
*>l110.0.0.0/16       0.0.0.0                           100      32768 i
*>l110.1.0.0/16       0.0.0.0                           100      32768 i
*>l110.128.0.0/16     0.0.0.0                           100      32768 i
*>l110.255.0.0/16     0.0.0.0                           100      32768 i           

 7. IANA の考慮事項本文書では、セクション4で、[RFC5492]のケイパビリティ・オプション・パラメータにおける拡張ネクストホップ・エンコーディング・ケイパビリティを示す新しいケイパビリティ・コードを定義している。この新しいケイパビリティ・コードの値は5で、[RFC5226] で定義されている「IETFレビュー」ポリシーを使用して割り当てるために確保されている範囲内である。

 8. セキュリティに関する考慮事項本文書は、BGP-4およびBGP-4のマルチプロトコル拡張に関するもの以外のセキュリティ問題を提起するものではない。同じセキュリティ・メカニズムが適用できる。
一般的なケースではないと予想されるが、BGPネクストホップ・アドレスとして使用されるIPv6アドレスは、IPv4射影IPv6アドレス([RFC4291]で定義)の可能性がある。ネットワーク・オペレータが導入する可能性のあるセキュリティ・メカニズムの設定(ネクストホップ・アドレスのセキュリティ・チェックなど)では、このケースも考慮する必要がある。

 9. 謝辞著者は、本文書で定義されているアプローチに貢献してくれたヤコフ・レクター、プラナフ・メータ、ジョン・スカダーに感謝する。

 10. 参考文献
 10.1. 引用規格[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2545]  Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999.
[RFC3107]  Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.
[RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC5492]  Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, February 2009.

 10.2. 参考規格[DYN-CAP]  Chen, E. and S. Sangli, "Dynamic Capability for BGP-4", Work in Progress, November 2006.
[L2VPN-SIG]  Rosen, E., "Provisioning, Autodiscovery, and Signaling in L2VPNs", Work in Progress, May 2006.
[MESH-FMWK]  Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", Work in Progress, February 2009.
[RFC4659]  De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006.
[RFC4684]  Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, November 2006.
[RFC4798]  De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007.
[RFC4925]  Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007.
[RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

 著者のアドレスフランソワ・ル・フォシュール

Cisco Systems

Greenside, 400 Avenue de Roumanille

Sophia Antipolis 06410

フランス

Eメール: flefauch@cisco.com
エリック・ローゼン

Cisco Systems

1414 Massachusetts Avenue

Boxborough, MA 01719

アメリカ

Eメール: erosen@cisco.com

 更新履歴2024.10.18
番号	説明	リファレンス
1	IP (IPバージョン4)
2	IP (IPバージョン6)
25	L2VPN情報のためのAFI	[RFC4761] [RFC6074]
値	説明	リファレンス
1	ユニキャスト・フォワーディングに使われるネットワーク層到達性情報	[RFC4760]
2	マルチキャスト・フォワーディングに使われるネットワーク層到達性情報	[RFC4760]
4	MPLSラベル付きネットワーク層到達性情報	[RFC8277]
65	仮想プライベートLANサービス(VPLS)	[RFC4761] [RFC6074]
128	MPLSラベル付きVPNアドレス	[RFC4364] [RFC8277] [RFC9252]
132	経路ターゲットの制約	[RFC4684]