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:23 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 74FE212038B for <idr@ietfa.amsl.com>; Wed, 26 Jun 2019 06:23:02 -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=unavailable 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 ZPuvB9JgjcrY for <idr@ietfa.amsl.com>; Wed, 26 Jun 2019 06:22:56 -0700 (PDT)
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 32EF812043F for <idr@ietf.org>; Wed, 26 Jun 2019 06:22:51 -0700 (PDT)
Received: by mail-qk1-x72c.google.com with SMTP id b18so1564467qkc.9 for <idr@ietf.org>; Wed, 26 Jun 2019 06:22:51 -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=TanpZKlgbN1YjfPVNP7uf06Cl5uO5EC+DjqI9hYcTdA=; b=fQZZgRbtoPLt++0HGvL5B0cR6B5IW70e6vMPrqDSv4lg57M3NjTnLJUDaXfsNQB9+d bX42xJk5Gmm2rb6fWfrncwCPsNOML+VhBS6gUFuff3ynDQkD83J63RZB9ESwnjR4MO8k mJlyMCJpnm09EtnxqwTVgvf0Vkv6mh4kC2NP3+9mEWz6MRsOsq65ugYGfRUKx2VGx24X ji63wgulL2p//GuolbjYbGq07eUP1VNjo4qZ/eJnLmineZAmGbyJDtPkWN4KJWxcHsB3 txmSPZoqDlJvMQGeSjFhIRmfvSHAkzhDYvQfzcqykqsG16Cw+GPD1/XBaTVGCMKjYu9h mdZA==
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=TanpZKlgbN1YjfPVNP7uf06Cl5uO5EC+DjqI9hYcTdA=; b=gJB3magDNlxzwQAVHQnAiXylaCUFkkHZkrJODDN2FaQROVeWIYKRlsxKpaAr9rDyCv C+xhsyJx4JI7tywpUSqPBu2tfQ9qxabWP4FOCn1dVGR7PgfYHnWpqsfIq2N/z3oAXhU0 VAQNFgSXXHrC5TdK5h2iuhqTtDv/DQA9rp8dr/cPoE/ZDgwq98Wo0O9I/Ok/e7SlPpw1 Xrxs2YWGBjrGgylA0QzhNh13TCV7/xJviJm4nhMg+o1sXMMvEnmNCwk4LVpPQxbO054s kaNPp0HP6nsb6NyEmFi+/6Rz0eksYat6QvrhYQK+FDTCc7luoT8fLYsjSkEMvWAvF6z5 etFA==
X-Gm-Message-State: APjAAAVFoK+BQQwvw3XwfFhYfxBsMZ26tvHD6KkmXuBJi8c1kkFsGhmE KWM+d6zFyKOgjl7QXHUBEny2OcNLBeOQe0UVi/DNBw==
X-Google-Smtp-Source: APXvYqxLfOHmmP++AyEufxZM4zrWAHTAPHv8o0ls6NLY22GeW1ZPSCILrAzCOgO0GQWMnqS4AMj2ZL6uw5lyENvjxV4=
X-Received: by 2002:a37:a80e:: with SMTP id r14mr3870409qke.134.1561555370036; Wed, 26 Jun 2019 06:22:50 -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>
In-Reply-To: <B17A6910EEDD1F45980687268941550F4D87EC92@MISOUT7MSGUSRCD.ITServices.sbc.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 26 Jun 2019 15:22:36 +0200
Message-ID: <CAOj+MMGEokGhMG+sAvPF0ob4Z1SK5Qwxyp66ULQXT6hzOLuUEA@mail.gmail.com>
To: "UTTARO, JAMES" <ju1738@att.com>
Cc: Xiejingrong <xiejingrong@huawei.com>, "idr@ietf.org" <idr@ietf.org>, "ian.farrer@telekom.de" <ian.farrer@telekom.de>, "ianfarrer@gmx.com" <ianfarrer@gmx.com>, "softwires@ietf.org" <softwires@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002151fd058c39f1b1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/eRAExrEAxsfiVVZvVom3dqncA1I>
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:23:08 -0000
And just to self complete the last sentence ... The same leading zeros were also added to SAFI 128 in the next hop field as to match the length of RD:IP prefix of the L3VPN NLRI. Original 2547 or subsequent 4364 did not define explicitly that the size of the next hop could be inferred from the nh length field - just took verbatim from 4760 that next hop is identified by AFI/SAFI of the NLRI itself . But in general MP-BGP spec does not limit protocol designers. When you define a new SAFI you are free to say that format of next hop will be inferred from its length field or that next hop may not be present at all as it does not make sense for a given SAFI (ref 5575) and that in turn will be indicated by zero nh length Many thx, R. On Wed, Jun 26, 2019 at 3:06 PM UTTARO, JAMES <ju1738@att.com> wrote: > *+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=> > >
- 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