Re: [v6ops] [Idr] Please discuss the use cases for draft-xie-idr-mpbgp-extention-4map6
Ketan Talaulikar <ketant.ietf@gmail.com> Sat, 16 March 2024 10:19 UTC
Return-Path: <ketant.ietf@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F83EC14F5F2; Sat, 16 Mar 2024 03:19:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.094
X-Spam-Level:
X-Spam-Status: No, score=-6.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6t3JiWgGsBup; Sat, 16 Mar 2024 03:19:13 -0700 (PDT)
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2460DC14F5ED; Sat, 16 Mar 2024 03:19:13 -0700 (PDT)
Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-a468004667aso247958366b.2; Sat, 16 Mar 2024 03:19:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710584351; x=1711189151; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=A0pVlLCo4q6N4HgqhPoa3c4cuJr5RX0XwXa5STqsU84=; b=OWLpPR6LOskUiv0RRJqwbBUo7cOLeDUbt/tCzZ51qwCh9gwBw3cxf7TpPV6yZ4m8XA hbbEjpV3M+LVYCpHSmmXC+R+nsF58RW+FyPQmesPTGiNReJiwYIwn+w5phv2704UArta 9xO0DjHbCp5FmtMKn6wzpAs1aR24Pkg5btcemOxHDpDkudgNUHyr5WVRbn50VBZCYNlq e+CzmRYj76e4nIkwkYh3UHXJXqz/HcN3rPgesI9ycMWCx6PHaWgix7MdIFogefhu2Nx5 6pvMNxSRa2/j4B1g3kwt7WSwwqNdMzGrIVKs6JazeLgtWTSPgN7dYFTvi2jgrX8JjveD wClw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710584351; x=1711189151; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=A0pVlLCo4q6N4HgqhPoa3c4cuJr5RX0XwXa5STqsU84=; b=NvbjM1p1ovVdOP5flxA0YVXtFtixz+F85/2KU8eU1/ivto1V/h5pIMPyS8fdrBSYAO +fjnL6kix1KpO7MkzfuI1nD6CjMgAAzq+SYxDgeqCRUah25VDBniVibmaQxeYIMoVDpo bbt1onhLWsBF7F5Gua+k7I9HAROnchVqJJ6hYTTtftXY7iCN00xm4E6UgKj2tQrFPCzy fsYsytpBmMQPVBuCdF0hSG+I47SSz6sRYKmxDpvmu2cSKuyZzoeig6yI8spaKgP0WFge H/H2rQqC3+nI7UGwYG2f+4+hqLP+jh3WOKAt7/yKmgXmNG3cqlrzj7tfDo+FyQKsGU3Y A5Jw==
X-Forwarded-Encrypted: i=1; AJvYcCUgIqQsnxXa5yVVI/4iRuDIdzH3f/X/SJEt3QcahtAPPoAPpKLSzETbnLpkeCrdNFek4K/wB/CCBQk+90P37PZ/51z5/sk2PD8FUmj7
X-Gm-Message-State: AOJu0YxZV7C8AH/OAlQ2CbGaIDTYo5VTboQPz80oct73ef6BLhZeP/N2 UdY4QK94j2QgkqLIbSqqdF+s3xygarKa6oI/0he+zk4j4tC30zV2qGUVcSzY5lotSYmxKvo0Xwa 3XscLrvG2lwCpKwy2tp3nVYW9zp8=
X-Google-Smtp-Source: AGHT+IEdS1bzpElKZwKmrIl58HmRFI9XqErzSFTjt1GXxcH8R/6hc4GD7gkfsUHkhn+kfPmoAeiN0dZ5V5VhEozsTbE=
X-Received: by 2002:a17:906:b305:b0:a46:650c:29ae with SMTP id n5-20020a170906b30500b00a46650c29aemr4476330ejz.67.1710584351050; Sat, 16 Mar 2024 03:19:11 -0700 (PDT)
MIME-Version: 1.0
References: <BYAPR08MB487294F5C1EE87A8184EDC8BB3AEA@BYAPR08MB4872.namprd08.prod.outlook.com> <tencent_CBB12F958C85FDF962D76180EB1C51662408@qq.com> <20240122223242.GA29681@pfrc.org> <tencent_446B00493916CCB662EB2AC90A17F2AFAF09@qq.com> <DB175FC2-BD0A-424A-B8E6-31345BEAC8D6@pfrc.org> <tencent_FF24FFF11A1B308B03C3EC27F6B8B2B09005@qq.com> <F64BDA83-5A46-4FEA-AD6F-16CDDD817EAA@pfrc.org> <tencent_6F855FF963D740807C1C166681B1FD950908@qq.com> <CAH6gdPzMfZ8NFXcGiMkFJu_=eA9jAW+oj6ir4sbaVvyAzbzzEQ@mail.gmail.com> <tencent_BE90355FEE1A05D09F03C18C2276AB72A705@qq.com> <CAOj+MMHuEbM-7BRNMNdv8s_pYqTWfw055WhOAvro8qX9Uoa_ow@mail.gmail.com> <tencent_6501D6701898ADC4EA57061416E7975F2B0A@qq.com> <CAOj+MMH_5L3tFmku=iew7fHBZuanWC3CTenQgAdJBPkPJxGBgQ@mail.gmail.com>
In-Reply-To: <CAOj+MMH_5L3tFmku=iew7fHBZuanWC3CTenQgAdJBPkPJxGBgQ@mail.gmail.com>
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Sat, 16 Mar 2024 15:48:59 +0530
Message-ID: <CAH6gdPwXXH78_xcib7QK+npdr9=gM+1_=q8Fvv8qnj2Ppx6wpw@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: Chongfeng Xie <chongfeng.xie@foxmail.com>, idr <idr@ietf.org>, v6ops@ietf.org
Content-Type: multipart/alternative; boundary="0000000000009a56120613c474a3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/mFIWRoDkmZixg_e3F_Df5wc8QWc>
Subject: Re: [v6ops] [Idr] Please discuss the use cases for draft-xie-idr-mpbgp-extention-4map6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Mar 2024 10:19:17 -0000
Hi Robert, Let me share some pointers and my analysis that you can cross-check/review. Having another pair of eyes/perspective would be helpful in clearing my understanding as well. Those aspects/details that you are looking for are coming from https://datatracker.ietf.org/doc/draft-ietf-v6ops-framework-md-ipv6only-underlay/ which is an informational document in v6ops WG (therefore copying them). Disclaimer: I am not an expert on these IPv6 mapping/transition techniques. I believe the crux of the matter is this piece: https://www.ietf.org/archive/id/draft-ietf-v6ops-framework-md-ipv6only-underlay-04.html#section-6.2 which seeks to put this "translation" function in a PE router. Which by itself is OK. But I have some basic concerns on this proposal and I will refer to text from the v6ops WG draft as well: 1) Why is back/forth translation required when there are encapsulation methods available that preserve the end to end sanctity of the end user packets? From https://www.ietf.org/archive/id/draft-ietf-v6ops-framework-md-ipv6only-underlay-04.html#name-overview Take the latter case as an example, when IPv4 packets that need to traverse lPv6-only network, the ingress PE, i.e., PE1, will *convert IPv4 packets into lPv6 packets by translation* or encapsulation and send them into IPv6 network. After intra-domain and cross-domain transmission, the IPv6 packets reach the egress PE, i.e., PE2, *then be restored to IPv4 packets*. I can understand the use of translation when an IPv4-only client is talking to an IPv6 server. I am having a tough time understanding why IETF would bless the translation back/forth simply to carry the traffic over an IPv6-only underlay (as the draft says)? 2) Now, if we were to remove this requirement for back/forth translation then every (PE) router would be providing this mapping services for IPv4-only hosts behind it. In that case, what we need is: (a) The PE router needs to know/learn which IPv4 destinations are in fact IPv6-only and therefore need to be mapped to IPv6. Assuming those IPv4 prefixes are learnt via AFI 1 SAFI 1, we need an indication in BGP that these routes need translation - perhaps a community or something more well-known? (b) The PE router needs to know/learn what IPv6 prefix is available for such a mapping function. Not sure if this requires BGP protocol extensions since there are many mapping techniques already deployed that don't seem to need one. Refer https://www.ietf.org/archive/id/draft-ietf-v6ops-framework-md-ipv6only-underlay-04.html#name-introduction (c) The PE router needs to advertise the IPv6 mapped prefixes corresponding to IPv4 prefixes that are hosted behind it. I assume that AFI 2 SAFI 1 can be used for such advertisements. These prefixes can be determined as part of (a) and could be "imported" from AFI 1 SAFI 1 after mapping on the PE router locally. It is likely that I am missing something here ... as I've been saying since the adoption poll for this document in IDR. But I have not seen a clear and crisp answer to justify this BGP extension. Are you (or anyone) able to help cross-check/correct my understanding? Thanks, Ketan On Sat, Mar 16, 2024 at 2:43 PM Robert Raszuk <robert@raszuk.net> wrote: > Dear Chongfeng, > > When you need to transport IPv4 packet over IPv6 core and you want to do > it via translation just swapping the address is not enough. You need to > deal with *all* other IPv4 and IPv6 header elements and describe how they > are going to be mapped when you are "translating" IPv4 header to IPv6 > header on ingress and the reverse operation on egress. > > Typically customers do not want transit to touch their header bits so > translation transparency becomes often the requirement. > > In your draft you are just describing how to signal the address > translation in BGP. But in which document there is clear description how to > map all other fields of IPv4 header and how to assure their transparent > reappearance on the other side of the transit ? > > Kind regards, > Robert > > > On Sat, Mar 16, 2024 at 1:40 AM Chongfeng Xie <chongfeng.xie@foxmail.com> > wrote: > >> Hi Robert, >> >> I understand that VPN4 is about encapsulation. As mentioned before, the >> new extension in my draft focuses on the case of IPv4 delivery over >> multi-domain IPv6-only underlay network, it can support not only IPv4/IPv6 >> encapsualtion, but also IPv4/IPv6 translation simultaneously. Translation >> is important transition mechanism, it has been widely developed. From the >> perspective of an operator, it is better for a unified control plane to >> support all possible functions at the data plane. Further more, address >> mapping mechanism from IPv4 to IPv6 has several advantages for network >> operation, which have been discussed before. >> >> Thank you very much. >> >> Chongfeng >> >> >> *From:* Robert Raszuk <robert@raszuk.net> >> *Date:* 2024-03-11 00:23 >> *To:* Chongfeng Xie <chongfeng.xie@foxmail.com> >> *CC:* ketant.ietf <ketant.ietf@gmail.com>; idr <idr@ietf.org> >> *Subject:* Re: [Idr] Please discuss the use cases for >> draft-xie-idr-mpbgp-extention-4map6 >> Hi Chongfeng, >> >> > It adopts address mapping rule which is the 1:1 mapping between IPv4 >> address and IPv6 address >> >> Let's assume that you are talking about prefixes not actual addresses as >> this is what draft says. >> >> But I have a fundamental question as an alternative to this proposal: >> >> Why not to use VPNv4 with IPv6 next hops as is without changing anything >> in the protocols or shipping implementations ? >> >> At min please kindly document pros and cons of using VPN signalling to >> accomplish the very same outcome. For transport as you know VPNs can run >> over lot's of data plane options: IPv6, SRv6 etc ... >> >> Note that if you would not propose a new SAFI I could see some benefits >> to what you are after ... but you do hence we better very well understand >> the reason for this extra dev and ops cost. >> >> Many thx, >> Robert >> >> >> On Sun, Mar 10, 2024 at 9:40 AM Chongfeng Xie <chongfeng.xie@foxmail.com> >> wrote: >> >>> >>> Hi Ketant, >>> >>> Sorry for my negligence of your mail accidentally. Actually your >>> question has been discussed early last year. I try to answer it again as >>> below, >>> >>> As mentioned The use case of 4map6 proposal in this draft is to support >>> IPv4aaS in the multi-domain IPv6-only networks. It adopts address mapping >>> rule which is the 1:1 mapping between IPv4 address and IPv6 address, and >>> IPv4 address become part of IPv6 address. With this design,PE devices can >>> map the source and destination addresses of IPv4 packets to the source >>> addresses of outer IPv6 packets, respectively. It mainly meets the >>> following requirements: >>> >>> 1)Compatibility with both encapsulation and translation, as we all know, >>> IPv4 service delivery over IPv6 network has two transition approaches: >>> Encapsulation and translation, both of them have been used in current >>> networks. 4map6 proposal can meet their needs simultaneously. Especially in >>> translation, it can support both doulbe translation and single translation. >>> >>> 2)Security,the outer IPv6 address is dynamically generated based on >>> mapping, and does not require a statically configured address as the tunnel >>> endpoint address in advance. This will be helpful to avoid the static IPv6 >>> address from becoming the target of the DDOS attack. >>> >>> 3)Load balancing,the 4map6 proposal assigns a corresponding IPv6 address >>> to each host's IPv4 address in the IPv6 network, and the IPv6 address newly >>> generated can more accurately identify the host. This allows for IPv6 >>> address based load balancing and management of the host in the IPv6 network >>> based on the IPv6 address. >>> >>> I hope this explanation can address your concerns. Welcome to continue >>> the discussion. >>> >>> Best regards >>> Chongfeng >>> >>> >>> ------------------------------ >>> chongfeng.xie@foxmail.com >>> >>> >>> *From:* Ketan Talaulikar <ketant.ietf@gmail.com> >>> *Date:* 2024-02-12 22:57 >>> *To:* Chongfeng Xie <chongfeng.xie@foxmail.com>; >>> draft-xie-idr-mpbgp-extension-4map6 >>> <draft-xie-idr-mpbgp-extension-4map6@ietf.org> >>> *CC:* jhaas <jhaas@pfrc.org>; Susan Hares <shares@ndzh.com>; idr >>> <idr@ietf.org> >>> *Subject:* Re: [Idr] Please discuss the use cases for >>> draft-xie-idr-mpbgp-extention-4map6 >>> Hi Chongfeng/Authors, >>> >>> Thanks for your updates to the document. >>> >>> I am still struggling to find the answer to the question on why it is >>> necessary to perform mapping from IPv4 to IPv6 and then back to IPv4 when >>> providing IPv4 connectivity service over an IPv6 core? Why is it not >>> sufficient to simply encapsulate the IPv4 payload into any encapsulation >>> (e.g., IPv4-in-IPv6, SRv6, MPLS, GRE, etc.) using RFC8950 encoding for the >>> IPv4 unicast/VPN SAFI. These solutions are documented >>> in draft-mishra-idr-v4-islands-v6-core-4pe >>> >>> Perhaps I am missing something and it would help me understand the need >>> for such mapping by service provider PE routers. >>> >>> Thanks, >>> Ketan >>> >>> >>> On Thu, Feb 8, 2024 at 5:14 AM Chongfeng Xie <chongfeng.xie@foxmail.com> >>> wrote: >>> >>>> >>>> >>>> Hi Jeff, >>>> >>>> We have submitted a new version of draft-xie-idr-mpbgp-extention-4map6. >>>> Based on your suggestions, the contents of new attribute is placed in a new >>>> TLV in the tunnel encapsulation attribute of RFC9012, and the format of the >>>> NLRI is revised as well. In addition, the section of operation has been >>>> changed accordingly. >>>> >>>> >>>> Name: draft-xie-idr-mpbgp-extension-4map6 >>>> Revision: 09 >>>> Title: MP-BGP Extension and the Procedures for IPv4/IPv6 >>>> Mapping Advertisement >>>> Date: 2024-02-09 >>>> Group: idr >>>> Pages: 16 >>>> URL: >>>> https://www.ietf.org/archive/id/draft-xie-idr-mpbgp-extension-4map6-09.txt >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-xie-idr-mpbgp-extension-4map6/ >>>> HTMLized: >>>> https://datatracker.ietf.org/doc/html/draft-xie-idr-mpbgp-extension-4map6 >>>> Diff: >>>> https://author-tools.ietf.org/iddiff?url2=draft-xie-idr-mpbgp-extension-4map6-09 >>>> >>>> We express sincere thanks to you for reviewing the draft as WG chair >>>> and providing a couple of important suggestions. We also thank idr WG for >>>> the comments and suggestions received so far. >>>> >>>> If you have any new comments or suggestions, please feel free to let me >>>> know. Thanks! >>>> >>>> Best regards >>>> Chongfeng >>>> >>>> >>>> *From:* 【外部账号】Jeffrey Haas <jhaas@pfrc.org> >>>> *Date:* 2024-02-05 00:02 >>>> *To:* Chongfeng Xie <chongfeng.xie@foxmail.com> >>>> *CC:* Sue Hares <shares@ndzh.com>; idr <idr@ietf.org>; >>>> draft-xie-idr-mpbgp-extension-4map6 >>>> <draft-xie-idr-mpbgp-extension-4map6@ietf.org> >>>> *Subject:* Re: [Idr] Please discuss the use cases for >>>> draft-xie-idr-mpbgp-extention-4map6 >>>> Chongfeng, >>>> >>>> >>>> On Jan 29, 2024, at 10:38 AM, Chongfeng Xie <chongfeng.xie@foxmail.com> >>>> wrote: >>>> Based on your comment and suggestions, we have made the following >>>> revisions and submitted a new version, >>>> >>>> >>>> >>>> [...] >>>> >>>> If you have any further comments, please feel free to let me know. >>>> >>>> >>>> Your changes significantly address my operational concerns. Thank you. >>>> >>>> -- Jeff >>>> >>>> _______________________________________________ >>>> Idr mailing list >>>> Idr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/idr >>>> >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>> >> _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >
- Re: [v6ops] [Idr] Please discuss the use cases fo… Ketan Talaulikar
- Re: [v6ops] [Idr] Please discuss the use cases fo… Robert Raszuk
- Re: [v6ops] [Idr] Please discuss the use cases fo… Ketan Talaulikar
- Re: [v6ops] [Idr] Please discuss the use cases fo… Robert Raszuk
- Re: [v6ops] [Idr] Please discuss the use cases fo… Ketan Talaulikar