RFC8950 Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop / RFC5549 Obsoleted

Published at 2020-11-20 | Last Update 2020-11-23

RFC5549 revision として RFC8950 が発行されました。 これにより RFC5549 は Obsolete になります。

ここに記載の内容や解釈に間違いがあるかもしれませんので、RFC原文をマスタとしてください。

• RFC5549からの変更点
• 参考資料

RFC5549からの変更点

ネクストホップアドレスのエンコード方法が変更され、ネクストホップアドレスは、24byte または 48byte の長さの VPNv6 prefix としてエンコードされるようになりました。

In [RFC5549], when AFI/SAFI <1/128> is used, the next-hop address is encoded as an IPv6 address with a length of 16 or 32 bytes. To accommodate all existing implementations and bring consistency with VPNv4oIPv4 and VPNv6oIPv6, this document modifies how the next-hop address is encoded. The next-hop address is now encoded as a VPN-IPv6 address with a length of 24 or 48 bytes (see Sections 3 and 6.2). This change addresses Erratum ID 5253 ([Err5253]). As all known and deployed implementations are interoperable today and use the new proposed encoding, the change does not break existing interoperability.

This document allows AFI/SAFI <1/129> (IPv4 multicast) to use an IPv6 underlay using similar encoding and procedures to AFI/SAFI <1/128> (see Sections 3 and 6.3).

MP_REACH_NLRI の nexthop length は次のようにエンコードされます。

# 変更前(RFC5549)
Length of Next Hop Network Address = 16 (or 32)

# 変更後(RFC8950)
Length of Next Hop Network Address = 24 (or 48)

なぜこのような変更が入ったのか、過去の複雑な経緯を簡単に解説します。

RFC5549 は簡単に言うと、MP-BGP によって IPv6トランスポート上でIPv4通信を実現するものですが、これは一種のVPNv4と言い換えることができます。

MP-BGPでは、ネクストホップアドレスフィールドで運ばれるアドレスが属するプロトコルが、AFIとSAFIによって決定されます。既存の多くのAFI/SAFIは、ネクストホップアドレスがNLRIとは異なるアドレスファミリに属することを可能にし、各種VPNサービスを実現しています。

さらに、既存のAFI/SAFIは、ネクストホップがIPv4プロトコルまたはIPv6プロトコルのどちらのプロトコルに属するかを判断するために、ネクストホップ情報のエンコーディングを指定しています。 例えば、ネクストホップアドレスの長さが4byteの場合はIPv4アドレスとして、16byteの場合はIPv6アドレスとして解釈されなければならないとしています。

RFC5549登場以前は、この VPNv4/v6 のネクストホップ情報のエンコーディングフォーマットがある意味きれいに決まっていました。代表的な BGP-MPLS VPN 仕様との比較は下記のようになります。

IPv4ネクストホップでのIPv6 NLRIのアドバイスには既存のソリューションがありますが、IPv6ネクストホップで IPv4 unicastまたはVPN-IPv4 NLRIをアドバイスするための特定のソリューションは存在しませんでした。

RFC5549 はこの隙間を埋めるソリューションでしたが、対応するBGPスピーカの実装で混乱を生みました。 それが、capability negotiationで期待するネクトホップ長(Nexthop length)の扱いです。

通常の IPv4 Unicast address の AFI/SAFI なら nexthop も IPv4 になります。 RFC5549は、IPv4 の nexthop を IPv6 にするというものですので、IPv4 over IPv6 Core での IPv6 nexthopの長さは 16byte(128bit) になります。

さらに、IPv4 VPN Unicast over IPv6 Core の場合のnexthopの長さは 16byte(128bit) に加えて、RD 8byte(64bit) が加算され、 24byte になります。RDには 0 がセットされます。

したがって、 BGPスピーカは extended nexthop encoding capability の capability negotiation を行う際に、nexthop length が 16 or 24 or more(32 or 48) であることを考慮しなければなりません。これは開発者の視点では大きな負担(のはず)です。

実際に主要な実装がどうなっているかというと、Network OS(BGP Daemon)によってバラバラです。 Junosのように16byteしか期待しない実装もあれば、VPNv6として24byteで実装しているNOSもあります。

複数のユーザから異なる実装でInteropに問題がある報告も寄せられています。

こうした背景を踏まえて、RFC5549revisionとなるRFC8950では、VPNv4 over IPv4 および VPNv6 over IPv6 との一貫性を持たせるために、ネクストホップアドレスのエンコード方法が変更されました。 ネクストホップアドレスは、24byteまたは48byteの長さのVPN-IPv6アドレスとしてエンコードされるようになりました。

以上。

参考資料

[bess] RFC 8950 on Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop
IETF106 slide: draft-litkowski-bess-vpnv4-ipv6-nh-handling