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

[Robert Raszuk <[e-mail]>]

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 <
[e-mail]> 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 <[e-mail]> написал(а):
>
> *+1*
>
> *From:* Idr <[e-mail]> *On Behalf Of *Robert Raszuk
> *Sent:* Wednesday, June 26, 2019 7:53 AM
> *To:* Xiejingrong <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> *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 <[e-mail]>
> 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:[e-mail]] *On Behalf Of *
> [e-mail]
> *Sent:* Tuesday, June 25, 2019 11:12 PM
> *To:* Zhuangshunwan <[e-mail]>; [e-mail]
> *Cc:* [e-mail]; [e-mail]
> *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 <[e-mail]> on behalf of Zhuangshunwan
> <[e-mail]>
> *Date: *Tuesday, 25. June 2019 at 13:18
> *To: *"[e-mail]" <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>
> *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:* [e-mail] [mailto:[e-mail] <[e-mail]>]
> *Sent:* Monday, June 24, 2019 8:08 PM
> *To:* Zhuangshunwan <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *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 <[e-mail]> 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
> [e-mail]
> 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
> [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
>
>