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

<ian.farrer@telekom.de> Tue, 25 June 2019 15:12 UTC

Return-Path: <ian.farrer@telekom.de>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9BB120372; Tue, 25 Jun 2019 08:12:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.297
X-Spam-Level:
X-Spam-Status: No, score=-4.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
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 nVf3ydo5IcnI; Tue, 25 Jun 2019 08:12:23 -0700 (PDT)
Received: from mailout31.telekom.de (mailout31.telekom.de [194.25.225.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 024101200FF; Tue, 25 Jun 2019 08:12:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1561475541; x=1593011541; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xjr65G49Mog7nmkO9VwKpVgAGK8JHB18T871boPTX58=; b=y6LQFYIVW+GqryWByS82zU5yQ1TbjrNmoOTRNBTaHkriuc+AB2bXdCCh iQzKNXGUg4Xr9/93/H+o9VQqaBJ6KAhyve1eiT9iybCgn8G3di+rA2cx/ gukunyG+kARjGJhi53bb3/pOZNM9nlW7sOGJCxKRREEL+k5txb90NS/Al mVg7CAh9ojEIbf/7eFxRRv3ajKwaeSl8amhyM/bD4cpI0KB3K6DkYIsEc dI7rmT2hBxaaP5cD4S2ZD6k9cLZLEuyA3d/FiZWIMfNdawHkI8T9aWuHS v5j/nDkA3snrdCKHzlznSoeNP44smAI8auSskjkdJx3ImkAybAyDauncX w==;
Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jun 2019 17:12:18 +0200
X-MGA-submission: =?us-ascii?q?MDEdipuzwK46jcFvf/nVeuu2JNmT5q1jv/NsNm?= =?us-ascii?q?NC3+Gd4j7QysQMNipJ3WTcVjvhkPx6fZktiOlRo+5eRDnNyX7lx3OLXS?= =?us-ascii?q?MRfoGePNlIGt0J2m5mkwlqqfiW/n/wIV209jPzvCHsli8tYWxTsDYYKH?= =?us-ascii?q?NeWSrfor1cpswKgMfovSwMpg=3D=3D?=
Received: from he199745.emea1.cds.t-internal.com ([10.169.119.53]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES256-SHA; 25 Jun 2019 17:12:19 +0200
Received: from HE199743.EMEA1.cds.t-internal.com (10.169.119.51) by HE199745.emea1.cds.t-internal.com (10.169.119.53) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 25 Jun 2019 17:12:19 +0200
Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE199743.EMEA1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 25 Jun 2019 17:12:19 +0200
Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.24) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 25 Jun 2019 17:12:17 +0200
Received: from LEXPR01MB0189.DEUPRD01.PROD.OUTLOOK.DE (10.158.164.14) by LEXPR01MB1215.DEUPRD01.PROD.OUTLOOK.DE (10.158.163.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Tue, 25 Jun 2019 15:12:18 +0000
Received: from LEXPR01MB0189.DEUPRD01.PROD.OUTLOOK.DE ([fe80::70a5:6b2d:cf8e:10f6]) by LEXPR01MB0189.DEUPRD01.PROD.OUTLOOK.DE ([fe80::70a5:6b2d:cf8e:10f6%2]) with mapi id 15.20.2008.017; Tue, 25 Jun 2019 15:12:17 +0000
From: <ian.farrer@telekom.de>
To: <zhuangshunwan@huawei.com>, <ianfarrer@gmx.com>
CC: <softwires@ietf.org>, <bess@ietf.org>
Thread-Topic: [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549
Thread-Index: AdUoywhLB5bsk43hQOStVculmHkjLwBunIeAADCC7YAADGdwgA==
Date: Tue, 25 Jun 2019 15:12:17 +0000
Message-ID: <B577834D-4010-42DF-AF28-690A1BD2A5AC@telekom.de>
References: <19AB2A007F56DB4E8257F949A2FB9858E5BDBB89@NKGEML515-MBS.china.huawei.com> <9DB8FCD5-DD04-4EB1-AEA5-A33B5B6F1BC4@gmx.com> <19AB2A007F56DB4E8257F949A2FB9858E5BE201C@NKGEML515-MBS.china.huawei.com>
In-Reply-To: <19AB2A007F56DB4E8257F949A2FB9858E5BE201C@NKGEML515-MBS.china.huawei.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.b.190609
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ian.farrer@telekom.de;
x-originating-ip: [2003:1c09:21:c00:500a:7881:468:516]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 416529ab-e0ea-40d0-5be6-08d6f97f8360
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LEXPR01MB1215;
x-ms-traffictypediagnostic: LEXPR01MB1215:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <LEXPR01MB121545D888301D057C9B8DD0FCE30@LEXPR01MB1215.DEUPRD01.PROD.OUTLOOK.DE>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0079056367
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(376002)(136003)(366004)(346002)(199004)(189003)(52396003)(7736002)(81166006)(81156014)(66476007)(66446008)(8676002)(2501003)(8936002)(66574012)(16799955002)(5660300002)(476003)(46003)(2616005)(64756008)(446003)(11346002)(53936002)(76116006)(68736007)(73956011)(66946007)(66556008)(86362001)(54906003)(6116002)(110136005)(33656002)(74482002)(6306002)(486006)(229853002)(236005)(316002)(36756003)(54896002)(58126008)(102836004)(76176011)(53546011)(71200400001)(6246003)(966005)(606006)(71190400001)(14454004)(256004)(478600001)(186003)(2906002)(75402003)(4326008)(518174003); DIR:OUT; SFP:1101; SCL:1; SRVR:LEXPR01MB1215; H:LEXPR01MB0189.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: OC2BJj4cMPdGL9AildtbOA/hXIrIS00/gtQrUNfteZcwRP1fpPH/LYY5AnEX0fh2ZOkx/nJopTEpjMn4/KzYu0iSLg8a4hgX1Ru+T7lY/WiHVm4IGR4T4iMVpqehNdKImAKOiWHJdLISxuen4EQiH9IBGaDOgUPzeU+6eA+XpJ524pFfCZkf+xyqfyULKT5yWqSJR8hH83Q2i3Fs3PpdvdXnSQVJV2QysIZZt8L9A1lncKigRw8V9gEoKaRGIufB1XcZmmHgyEpZR3wJLT3T6DFtgAixwDwCMm2Q+rxrXvdUxz1BkbuUIs/18SfqNMl7WtelnkBxXZjYop6qEtDmTj1jWp6j1Mv1K7TUdAUvCUMPqr+mEMYUPKZbqjRoJ2MLERvJhyLuvqEpGYxlOqyPoLske2REo/6oca7SVCPhpMI=
Content-Type: multipart/alternative; boundary="_000_B577834D401042DFAF28690A1BD2A5ACtelekomde_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 416529ab-e0ea-40d0-5be6-08d6f97f8360
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2019 15:12:17.9476 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ian.farrer@telekom.de
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEXPR01MB1215
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/vlaEa5fSIFdClPneaEfL8Nfk2T0>
Subject: Re: [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jun 2019 15:12:27 -0000

Hi Shunwan,

I’ve just re-checked RFC5539, and the referenced section 3 of RFC2545 and I can find nothing about using VPN-IPv6 for encoding the next-hop. Section 3 of RFC5539 is very clear that it’s a 16-byte GU IPv6 address or 32-bytes with a GU and LL address.

Can you point me to the text that gives you the impression that VPN-IPv6 is correct?

Note – I see that there is reported Errata on RFC5549, (not verified) saying that the length should be 24 or 48 to include the RD. However, as mentioned above, the supporting text in multiple places in the RFC and its references support the use of an IPv6 address (or 2) with no RD at 16 or 32 bytes, so this does seem to be the intention of the document as written.
https://www.rfc-editor.org/errata_search.php?rfc=5549

Thanks,
Ian

From: Softwires <softwires-bounces@ietf.org> on behalf of Zhuangshunwan <zhuangshunwan@huawei.com>
Date: Tuesday, 25. June 2019 at 13:18
To: "ianfarrer@gmx.com" <ianfarrer@gmx.com>
Cc: "softwires@ietf.org" <softwires@ietf.org>rg>, "bess@ietf.org" <bess@ietf.org>
Subject: Re: [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

Hi Ian,

Thanks for your response!

The opinion I have collected is:
Per RFC4634, the IPv4-VPN routes shall carry the V4 Next-hop, beginning with an 8-octet RD and ending with a 4-octet IPv4 address.
Per RFC4659, the IPv6-VPN routes shall carry the V6 Next-hop, beginning with an 8-octet RD and ending with a 16-octet IPv6 address.
When we start to implement the IPv4 VPN over IPv6 Core,  it is a natural way to encode the IPv4-VPN routes with VPN-IPv6 next-hop (i.e. beginning with an 8-octet RD and ending with a 16-octet IPv6 address) .

I believe this is not just a minority opinion, and some of the current implementations are also doing this way.

I hope that the WGs can give a consistent opinion on this issue and avoid interoperability problem in the future.

Thanks,
Shunwan

From: ianfarrer@gmx.com [mailto:ianfarrer@gmx.com]
Sent: Monday, June 24, 2019 8:08 PM
To: Zhuangshunwan <zhuangshunwan@huawei.com>
Cc: bess@ietf.org; softwires@ietf.org
Subject: Re: [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

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<mailto: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