Re: [bess] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

ianfarrer@gmx.com Mon, 24 June 2019 12:08 UTC

Return-Path: <ianfarrer@gmx.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4822E120162; Mon, 24 Jun 2019 05:08:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42QaYguaMaPJ; Mon, 24 Jun 2019 05:08:22 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2656120111; Mon, 24 Jun 2019 05:08:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1561378088; bh=j7fkTiolWa+AgppWz/+vnwDkx7AsKonAVvsCLcH7sYQ=; h=X-UI-Sender-Class:From:Subject:Date:In-Reply-To:Cc:To:References; b=CfdQYqP0fQc13GVAlX8tQOzaCRjMDx0ZD5BvnRvneK5VpekivYPsaYtCnhizlCHep 7flv+XRdU6cLzvCXZZl47SgBMhwuJDK5+RI0v5eHdS8kNbv7dwwcKr/DHv+DcdCh5f lkk+o9gFiV1RETBCde5V6Vi1qYtFKlP/iFJWAh94=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.228] ([80.159.240.8]) by mail.gmx.com (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1Mgeo8-1iDJTn3bTQ-00h3VH; Mon, 24 Jun 2019 14:08:07 +0200
From: ianfarrer@gmx.com
Message-Id: <9DB8FCD5-DD04-4EB1-AEA5-A33B5B6F1BC4@gmx.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AD2D474E-89C6-4553-87C4-D9D61C2ADD69"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 24 Jun 2019 14:08:05 +0200
In-Reply-To: <19AB2A007F56DB4E8257F949A2FB9858E5BDBB89@NKGEML515-MBS.china.huawei.com>
Cc: "bess@ietf.org" <bess@ietf.org>, "softwires@ietf.org" <softwires@ietf.org>
To: Zhuangshunwan <zhuangshunwan@huawei.com>
References: <19AB2A007F56DB4E8257F949A2FB9858E5BDBB89@NKGEML515-MBS.china.huawei.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:i4DY3bzZKBr/byDJTCVCvtD29NMdX/NuPrya5UeWy3NnVj3uFMe iF/PkC7a5tvapLRCfrE53feJPO7ucDLf16Qs910xrgTae0EDmCQEmf5W7+dq4KdMU62s8b+ C0S5dIwl84VUsshl7298ewixr6h0nlsvUQ6t8HXX59I/etqQwzoq7PzloGANz0YB9vhmqUd zEBFP4fvTpmEJikfJoYrA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:d6LlL4sJ+zw=:MS90BbKO2aN/D6jsjeiDsQ OyvOPE2GANkFBpr1UWX6uQ4dij8g+p3ircQ/m0fWxWMpyI59dEH0w7z99ZL3w7wTsrSA+PLC4 NQ8T2gt93xX52/nhgAXkJg6phOUHAAJUUcg89Jth+DLjOr8MUxTEyDz3pYMEylEdgJFMcDGTz etBedZzysTTohmc9EXd+IWpxXvasOVtH8C+fOh63X7aAh6kuZ1fmb189kvdg7bhVo635+Ibtk 75MiFu6ZTSjch/RXNGDLI6mtssBH1RvDdbXnMlRWKYpo0975rKyA/0wudRvLukD5y1YucIGlr 0D1YgQTUFKtc44Sn7joK6lk59N38OOdItptgrID0611sdP8x+tC9jluqq9SDWpKXMoMhi/XBW 1sXfTEIGRovgjnmxop6HgTyXEZwrBZCrlrY43xOOBBh2sQGF8dpQ3a030RaxZa7ArVZWBrWjA 05/eltl4KCS/T0j3lyM/HT0KD7v8RDqR6meTg+K+iJeCAOlc4Hpre4AVQTp5JspdBTh6Ne3Ok I6TJOT/M0vQgPxlJkjv+VAtXm+bum9vbAbE99ZRlvcWxnSmvxuvkciVUAd6/4nwVuDto6ZMrS W98w/fjCkoMFA20/2aijXT3CYVohP3mRXfTDbSNsMO8Tmp+eBhEfr8HijfwnAfTK/towpcD9+ FT1uy5OjMLt5fD9xhNL3tQbROvktlRI+FVrR6Ot5fmWlyZa5KjnTgoH1vHHCpvlcrmFcfPZgC 1gSNocFO+jjzlNw+7/ARmppo1cxIoWsZ3QscW0boz7+QfPok2967FLD9oH11f/1AzQOuU2T40 FlbNCnUsddfjdigS01AqV3iXa/g4ri97wiNfVCc8DZrhJy/b3Ta1SQh3xDwgMdT8DunToeakA omF3XzJp/49Ee+Wzc3S+niLwdPxsrRTg8WVFvno2FNa11C78Mova3MDraHr+5E3i/6dTz0iah k6BEgQjPrkc40765PFeZVfrOv0VMkDTt7y8rdWEv+Xbn59yH2H4Gf
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/o-9My6abG1012Vq4vcyM_Q5pqlA>
Subject: Re: [bess] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jun 2019 12:08:24 -0000

Hi,

My reading of Section 3 of RFC5549 is that the v6 next-hop is encoded as an IPv6 address:
 
   The BGP speaker receiving the advertisement MUST use the Length of
   Next Hop Address field to determine which network-layer protocol the
   next hop address belongs to.  When the Length of Next Hop Address
   field is equal to 16 or 32, the next hop address is of type IPv6.

It’s also worth noting that RFC4659 Section 2 states:
 
A VPN-IPv6 address is a 24-octet quantity, beginning with an 8-octet
   "Route Distinguisher" (RD) and ending with a 16-octet IPv6 address.

So, not 16 or 32 bytes.

Thanks,
Ian


> On 22. Jun 2019, at 09:59, Zhuangshunwan <zhuangshunwan@huawei.com> wrote:
> 
> Dear authors and WGs,
>  
> RFC5549 Section 6.2 says: 
>  
> . 6.2.  IPv4 VPN over IPv6 Core
> . 
> .    The extensions defined in this document may be used for support of
> .    IPV4 VPNs over an IPv6 backbone.  In this application, PE routers
> .    would advertise VPN-IPv4 NLRI in the MP_REACH_NLRI along with an IPv6
> .    Next Hop.
> . 
> .    The MP_REACH_NLRI is encoded with:
> . 
> .    o  AFI = 1
> . 
> .    o  SAFI = 128
> . 
> .    o  Length of Next Hop Network Address = 16 (or 32)
> . 
> .    o  Network Address of Next Hop = IPv6 address of Next Hop
> . 
> .    o  NLRI = IPv4-VPN routes
>  
>  
> Regarding IPv4-VPN routes, RFC4634 Section 4.3.2 says:
>  
> . 4.3.2.  Route Distribution Among PEs by BGP
> [snip]
> .    When a PE router distributes a VPN-IPv4 route via BGP, it uses its
> .    own address as the "BGP next hop".  This address is encoded as a
> .    VPN-IPv4 address with an RD of 0.  ([BGP-MP] requires that the next
> .    hop address be in the same address family as the Network Layer
> .    Reachability Information (NLRI).)  It also assigns and distributes an
> .    MPLS label.  (Essentially, PE routers distribute not VPN-IPv4 routes,
> .    but Labeled VPN-IPv4 routes.  Cf. [MPLS-BGP].)  When the PE processes
> .    a received packet that has this label at the top of the stack, the PE
> .    will pop the stack, and process the packet appropriately.
> [snip]
>  
>  
> Question:
> RFC5549 defines "IPv4 VPN over IPv6 Core", When a PE router distributes a VPN-IPv4 route with an IPv6 Next-Hop via BGP, should the IPv6 Next-Hop be encoded as an VPN-IPv6 address with an RD of 0 ? 
>  
>  
> Thanks,
> Shunwan
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org <mailto:Softwires@ietf.org>
> https://www.ietf.org/mailman/listinfo/softwires <https://www.ietf.org/mailman/listinfo/softwires>