Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549
Robert Raszuk <robert@raszuk.net> Wed, 26 June 2019 13:27 UTC
Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAB01200F5 for <idr@ietfa.amsl.com>; Wed, 26 Jun 2019 06:27:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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=raszuk.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 PZIayQwwK1p4 for <idr@ietfa.amsl.com>; Wed, 26 Jun 2019 06:27:33 -0700 (PDT)
Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) (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 C4E27120119 for <idr@ietf.org>; Wed, 26 Jun 2019 06:27:32 -0700 (PDT)
Received: by mail-qk1-x743.google.com with SMTP id d15so1602743qkl.4 for <idr@ietf.org>; Wed, 26 Jun 2019 06:27:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7AUeSsaZsDAwylpKvmLyIEHgn2Z5ay/XsC8c8yTUneM=; b=K2KTHgGP52h4pJkf1dnkkX0RciZKVq4isXUw4mAwUU8lDaK99fP0HMMM+gUFl6c5Lr U6ET0Si3+jouX+u8PsRJXab7eqG9+Q4eGjckpevhfs2K+vIvm8KKtwJ6/f/q/2Ibn2qJ thZ95jzAv8f5N1wURnRauzsxqt1m4nZgWb9dRqkU7/4FaaItSHw5IKICE3dXIqExpfRa MtT+2Y7MAKWr7O5twq2e0+EX0diZYKSejhpborsmKh9298wgM8BSTSe0AxN1C4UHegOy ond9i8WaY9E1SbXEGlMOOJNTHUT5lClvK6V+e7JQs+dq5aNOszTWKM99mARfelgYfDzK iwXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7AUeSsaZsDAwylpKvmLyIEHgn2Z5ay/XsC8c8yTUneM=; b=XyS8MnbSUTg1wPI0QuYkR/SD42WdJnStrvqz+3pCUs6hvBiW4s8XkbW2ukVuC06+HN H3i9C9VhxAhHw3D/zqm1qPt1PFtP22xOmU/gHBfkf3GXvWv+yOp2jMsCvJJ349WgpsgL /Tbn46oNV4u16haSbX2OA2phixFkl1quXC0s1ZaMgJkq5ZO1rTDlN4nC7y9UJQ6uUobZ PgcSvWCUTkct0A5qad49Z+CqHmCL3dKJluFx2KZewFjV2RDK1cgmV3tdYDKoXLcBx3u2 ZeL0C3a1wnP3opl1dRX/+wRD2xE+HUgbL/2huUPai5K/QLXZrg35EOmN9gVBU4WErxDB QLkg==
X-Gm-Message-State: APjAAAWdA3Ik4vIbbDmYYRACltUfrRA5XTIXKClyN6nEXmr0jKZaoQXD bzgDIZkl9kCxVfwAdryVC2WQyaCQs1c6wLzAZZAvFA==
X-Google-Smtp-Source: APXvYqxNiUPJ9ITDICjLlZd6n4Kc8SLF3BqYY7N2KvTfDz858UHL/MEdFH1U5uchdcsqO9P3x2A/41+WOs5vCqqPaB8=
X-Received: by 2002:a05:620a:1285:: with SMTP id w5mr3630442qki.302.1561555651804; Wed, 26 Jun 2019 06:27:31 -0700 (PDT)
MIME-Version: 1.0
References: <19AB2A007F56DB4E8257F949A2FB9858E5BDBB89@NKGEML515-MBS.china.huawei.com> <9DB8FCD5-DD04-4EB1-AEA5-A33B5B6F1BC4@gmx.com> <19AB2A007F56DB4E8257F949A2FB9858E5BE201C@NKGEML515-MBS.china.huawei.com> <B577834D-4010-42DF-AF28-690A1BD2A5AC@telekom.de> <16253F7987E4F346823E305D08F9115AAB8D61CE@nkgeml514-mbx.china.huawei.com> <CAOj+MMGdoi1ROTmbuFu8eXWix6JfYwO1TCPUakyOEdTU01-1zA@mail.gmail.com> <B17A6910EEDD1F45980687268941550F4D87EC92@MISOUT7MSGUSRCD.ITServices.sbc.com> <8E1E4882-7850-4BF4-82EC-82BDFE9BF408@gmail.com>
In-Reply-To: <8E1E4882-7850-4BF4-82EC-82BDFE9BF408@gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 26 Jun 2019 15:27:18 +0200
Message-ID: <CAOj+MMGKN9drVzJgrE6WVkF6k43Vqe6TNwK9VpHpFbJTafKUdA@mail.gmail.com>
To: Alexander Okonnikov <alexander.okonnikov@gmail.com>
Cc: "UTTARO, JAMES" <ju1738@att.com>, Xiejingrong <xiejingrong@huawei.com>, "softwires@ietf.org" <softwires@ietf.org>, "idr@ietf.org" <idr@ietf.org>, "ian.farrer@telekom.de" <ian.farrer@telekom.de>, "bess@ietf.org" <bess@ietf.org>, "ianfarrer@gmx.com" <ianfarrer@gmx.com>
Content-Type: multipart/alternative; boundary="000000000000ec527e058c3a011f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Emqs87BqYy0UFTAmLsqSipX1t6A>
Subject: Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jun 2019 13:27:37 -0000
Hi Alex, > My understanding is follow: RD is encoded in Next Hop field That is subtle misinterpretation of the 4364 :) The text says: "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." That can be read as: A) Next hop field has prepended zeros to match the NLRI format of 8 octet RD + 4 octet IPv4 (for IPv4 case) B) Next hop is of format RD:IPv4 where RD=0 My recollection and number of direct discussions with authors of both2547/4364 & 4760 at that time leads me to believe we are dealing with A. Of course anyone can see option B as valid, but at the end of the day it is the same on the wire :) So I am not sure what exactly the problem or the question we are trying to answer is :) Cheers, R. On Wed, Jun 26, 2019 at 3:22 PM Alexander Okonnikov < alexander.okonnikov@gmail.com> wrote: > Hi, > > My understanding is follow: RD is encoded in Next Hop field, because > authors of RFC 4364, while referring to RFC 2858, were trying to make it > consistent with RFC 4760 (obsoletes RFC 2858). RFC 2858 says that Next Hop > field should match AFI. On the other hand, RFC 4760 says that Next Hop > Field should match combination of AFI/SAFI. Also, drafts of RFC 4364 and > RFC 4760 were being developed practically at the same time period. > > 26 июня 2019 г., в 16:05, UTTARO, JAMES <ju1738@att.com> написал(а): > > *+1* > > *From:* Idr <idr-bounces@ietf.org> *On Behalf Of *Robert Raszuk > *Sent:* Wednesday, June 26, 2019 7:53 AM > *To:* Xiejingrong <xiejingrong@huawei.com> > *Cc:* idr@ietf.org; ian.farrer@telekom.de; ianfarrer@gmx.com; > softwires@ietf.org; bess@ietf.org > *Subject:* Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network > Address coding for IPv4 VPN over IPv6 Core in RFC5549 > > All, > > RD is a property of the NLRI not next hop. I am not sure where in this > thread or some spec someone came to the conclusion that next hop field > should contain an RD. RD is not useful there and should never be part of > any next hop field. > > Remember RD role is to make prefix unique - that's it - no more no less. > Next hop uniqness is given by architecture and there is no need to make it > unique. > > In some cases when we need to carry IPv4 address in IPv6 next hop field > (there was historically some assumption that next hop must be of the same > AF as prefix) we prepend to it numerical zeros. > > Thx, > R. > > > > > > On Wed, Jun 26, 2019 at 1:40 PM Xiejingrong <xiejingrong@huawei.com> > wrote: > > Hi folks, > > I guess this is an inconsistency due to past carelessness. Is there anyone > can tell us the history of this inconsistency ? > RFC4364(VPNv4 over IPv4 network) and RFC4659(VPNv6 over IPv4 or IPv6 > network) both require to use RD+IP(v4 or v6 respectively) as nexthop. > RFC5549(VPNv4/IPv4 over IPv6 network) requires to use IPv6 without RD as > nexthop. > This same question also occur in MVPN: RFC6515, which talks about MVPN6 > over IPv4/IPv6, or MVPN over IPv6, but does imply loosely to use IPv4/IPv6 > without RD as nexthop (see below). > The purpose of this document is to make clear that whenever a PE > address occurs in an MCAST-VPN route (whether in the NLRI or in an > attribute), the IP address family of that address is determined by > the length of the address (a length of 4 octets for IPv4 addresses, a > length of 16 octets for IPv6 addresses), NOT by the AFI field of the > route. > > My suggestion: implementation should interpret nexthop RD+IPv4 and nexthop > IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6 the same. > The RFC5549/SRv6-VPN/RFC6515 can keep as current shape, while interoperate > can meet between different implementations. > Need a new draft to clarify this and to give a guide on further FooService > over FooNetwork ? > > Thanks > Jingrong > > *From:* Softwires [mailto:softwires-bounces@ietf.org] *On Behalf Of * > ian.farrer@telekom.de > *Sent:* Tuesday, June 25, 2019 11:12 PM > *To:* Zhuangshunwan <zhuangshunwan@huawei.com>; ianfarrer@gmx.com > *Cc:* softwires@ietf.org; bess@ietf.org > *Subject:* Re: [Softwires] Regarding the Next Hop Network Address coding > for IPv4 VPN over IPv6 Core in RFC5549 > > 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 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_errata-5Fsearch.php-3Frfc-3D5549&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=UIVZS5gA4_SHRLCgtb5AnrGyg_Rit-E-t_ZsSB8Z5hQ&s=333xV6xato3JrUqR7cF_lNHZ6cCgzHqaeva-aNH6ORY&e=> > > 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>, "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 <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> 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 > https://www.ietf.org/mailman/listinfo/softwires > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_softwires&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=UIVZS5gA4_SHRLCgtb5AnrGyg_Rit-E-t_ZsSB8Z5hQ&s=-VhqM-U7CXqqrJK30vJoT0RsvjQI4Kbnek9L-JvjNs8&e=> > > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=UIVZS5gA4_SHRLCgtb5AnrGyg_Rit-E-t_ZsSB8Z5hQ&s=JKi7zUQKOeE3U_Ii2m4n4NQcorfG6hvi8c7XZ1qywEs&e=> > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > >
- Re: [Idr] [Softwires] Regarding the Next Hop Netw… Xiejingrong
- Re: [Idr] [bess] [Softwires] Regarding the Next H… Robert Raszuk
- Re: [Idr] [bess] [Softwires] Regarding the Next H… UTTARO, JAMES
- Re: [Idr] [bess] [Softwires] Regarding the Next H… Alexander Okonnikov
- Re: [Idr] [bess] [Softwires] Regarding the Next H… Robert Raszuk
- Re: [Idr] [bess] [Softwires] Regarding the Next H… Robert Raszuk
- Re: [Idr] [bess] [Softwires] Regarding the Next H… Alexander Okonnikov
- Re: [Idr] [bess] [Softwires] Regarding the Next H… Xiejingrong
- Re: [Idr] [bess] [Softwires] Regarding the Next H… Vigoureux, Martin (Nokia - FR/Paris-Saclay)
- Re: [Idr] [bess] [Softwires] Regarding the Next H… Robert Raszuk
- Re: [Idr] [bess] [Softwires] Regarding the Next H… Xiejingrong
- Re: [Idr] [Softwires] [bess] Regarding the Next H… Rajiv Asati (rajiva)
- Re: [Idr] [Softwires] [bess] Regarding the Next H… Zhuangshunwan
- Re: [Idr] [bess] [Softwires] Regarding the Next H… Xiejingrong
- Re: [Idr] [bess] [Softwires] Regarding the Next H… Robert Raszuk
- Re: [Idr] [bess] [Softwires] Regarding the Next H… Zhuangshunwan
- Re: [Idr] [Softwires] [bess] Regarding the Next H… ian.farrer
- Re: [Idr] [bess] [Softwires] Regarding the Next H… stephane.litkowski
- Re: [Idr] [bess] [Softwires] Regarding the Next H… stephane.litkowski
- Re: [Idr] [bess] [Softwires] Regarding the Next H… Robert Raszuk
- Re: [Idr] [bess] [Softwires] Regarding the Next H… stephane.litkowski