[v6ops] Re: Traffic control protocols (PCP and UPnP IGD)

"jordi.palet@consulintel.es" <jordi.palet@consulintel.es> Fri, 26 July 2024 18:39 UTC

Return-Path: <prvs=19377bc400=jordi.palet@consulintel.es>
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 4A336C14F747 for <v6ops@ietfa.amsl.com>; Fri, 26 Jul 2024 11:39:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level:
X-Spam-Status: No, score=-2.003 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, 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 (1024-bit key) header.d=consulintel.es
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 BN_tDZhMytCi for <v6ops@ietfa.amsl.com>; Fri, 26 Jul 2024 11:39:41 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CF1BC1D5304 for <v6ops@ietf.org>; Fri, 26 Jul 2024 11:39:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1722019167; x=1722623967; i=jordi.palet@consulintel.es; q=dns/txt; h=From:Content-Type: Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id; bh=v8u4kFdFDoEwQx3PTl5FbCzcdwUYE6OKlb/hNwFnMO8=; b=eWtRkt+oyCrKh TFwf3IbEkusrldeodrdEowapH2sbdIvQ1cYr1hvH20Li+kP0rGaOskPn+BnLsO9F sVkLmGfdScHzUSkWjYOEwypmmah7HjOVbWleJvT6YSfIb9prjwqqP/SqyJ4L+NFO 24/fIaFHJGDv0tP4+cJySzAf0ijr/E=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Fri, 26 Jul 2024 20:39:27 +0200
X-Spam-Processed: mail.consulintel.es, Fri, 26 Jul 2024 20:39:25 +0200
Received: from smtpclient.apple by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50001589454.msg for <v6ops@ietf.org>; Fri, 26 Jul 2024 20:39:24 +0200
X-MDRemoteIP: 10.8.10.10
X-MDHelo: smtpclient.apple
X-MDArrival-Date: Fri, 26 Jul 2024 20:39:24 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=19377bc400=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
From: "jordi.palet@consulintel.es" <jordi.palet@consulintel.es>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F84C5A69-4F40-48FD-A21B-C05C1DA03642"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
Date: Fri, 26 Jul 2024 11:39:07 -0700
References: <73141FE4-DA01-4B9F-88F3-EE68FBD2A0CB@apple.com> <TYVPR01MB10750A78CA08E3D2EB6CCEB37D2AB2@TYVPR01MB10750.jpnprd01.prod.outlook.com> <CAPt1N1mhViWNxWw1XKQZyMwFWWdUQ3doh-u6pezYoFhpA8b8Qg@mail.gmail.com> <TYVPR01MB10750FB6A5FA4EB034F9B5B8AD2B42@TYVPR01MB10750.jpnprd01.prod.outlook.com> <CAPt1N1kA9KETiVsK744m5AaXvCnspsN8zkdqRR1OcMo-ftkNfA@mail.gmail.com> <TYVPR01MB10750B17554096318B8C49BACD2B42@TYVPR01MB10750.jpnprd01.prod.outlook.com> <BF9C2E26-E49C-4764-9CEA-8E7738801819@employees.org> <CACyFTPFiNjvBKbCbNv-yk9NuNW3JJEJA9KBhsD06EdgrZQmFKw@mail.gmail.com> <CAPt1N1=SJNe+_dtufY8sMOydgqtGatxp0M9Vd4dOecxqo9zE7g@mail.gmail.com> <CACyFTPFoepzuDcEBnn2dt9v1Kt32ALxuBwoNwh9=8Qca=ihOoQ@mail.gmail.com> <TYVPR01MB107504A021B4A90CAEC2AAE0BD2B42@TYVPR01MB10750.jpnprd01.prod.outlook.com> <CACyFTPGQPme1NHzOc1Cvdydx=Jg1+2SzppTy305jw4UFzJkvwg@mail.gmail.com> <TYVPR01MB10750B5C9FD7FEF601FE6F660D2B42@TYVPR01MB10750.jpnprd01.prod.outlook.com> <CACyFTPHKrvQDpxs1ji+qWjb66BFyBhiM=E1DZbmRfhCyAkdRpw@mail.gmail.com> <TYVPR01MB1075016D628F2EDD3907F4F4AD2B42@TYVPR01MB10750.jpnprd01.prod.outlook.com> <CACyFTPHo6QTBeLeh2SmmxdU_sOH5iFfgnFBhjWDDQK0Xte0vXg@mail.gmail.com>
To: "v6ops@ietf.org" <v6ops@ietf.org>
In-Reply-To: <CACyFTPHo6QTBeLeh2SmmxdU_sOH5iFfgnFBhjWDDQK0Xte0vXg@mail.gmail.com>
Message-Id: <D8650B16-8319-49A1-8E1E-57F29B45BA08@consulintel.es>
X-Mailer: Apple Mail (2.3774.600.62)
Message-ID-Hash: 2NAJAFDLQKHEOT7GSZBMI5A3SEIHE3ZH
X-Message-ID-Hash: 2NAJAFDLQKHEOT7GSZBMI5A3SEIHE3ZH
X-MailFrom: prvs=19377bc400=jordi.palet@consulintel.es
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-v6ops.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [v6ops] Re: Traffic control protocols (PCP and UPnP IGD)
List-Id: v6ops discussion list <v6ops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Nyy6dp86qabkWiH1SzPxIuDePqw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Owner: <mailto:v6ops-owner@ietf.org>
List-Post: <mailto:v6ops@ietf.org>
List-Subscribe: <mailto:v6ops-join@ietf.org>
List-Unsubscribe: <mailto:v6ops-leave@ietf.org>

In general, according to my deployment experience, 464XLAT is more efficient, considering:
1) You don’t have to preallocate a number of ports per customer, so customers don’t have ports limitations, and you have a better utilization of your IPv4 public pools.
2) Services such as PSN black-list (forever) IPv4 pools used by CGN, MAP, etc., but I’ve not seen that happening with 464XLAT.
3) The amount of IPv6 traffic in 464XLAT deployments usually is much higher than the IPv4 one, if the deployment is done correctly, so the “state” in the NAT64 is lower and lower. T-Mobile reported, several years ago 24% only, but I’ve deployed in customers where it is much lower. So the impact in NAT64 becomes not an issue.
4) If you have wired and cellular networks, you can use a single transition mechanism (464XLAT), instead of 2, so less complexity. Also much easier to provide a CPE with fallback from (for example) fiber to LTE using 464XLAT in both cases. Remember that ONLY 464XLAT is supported by mobile.

https://datatracker.ietf.org/doc/rfc9313/
RFC 9313: Pros and Cons of IPv6 Transition Technologies for IPv4-as-a-Service (IPv4aaS)
datatracker.ietf.org

Regards,
Jordi

@jordipalet


> El 26 jul 2024, a las 11:17, Daryll Swer <contact=40daryllswer.com@dmarc.ietf.org> escribió:
> 
> Brian, Kawashima
> 
> Yes, MAP-T is stateless on provider side. But to my understanding, correct me if I'm wrong:
> In 464xlat, IPv4 is limited ONLY to client-server model capped on layer 4 only to UDP/TCP.
> In MAP-T, IPv4 can do peer to peer via NAT punching (STUN) or augmented with PCP, in addition, since MAP-T pushes stateful-ness away from SP to CPE, it eliminates the classic problem of statefulness in traditional CGNAT (NAT444).
> 
> That being said, I've done many CGNAT deployments, and the statefulness in itself doesn't break IPv4 P2P traffic, if the CGNAT box is properly configured for EIM-NAT and layer 4 traversals for non-TCP/UDP, should a user want to use UDP-Lite or SCTP for example.
> 
> As far as I understand, mimicking this “Clean CGNAT” approach is easier to achieve on MAP-T, than it is on 464xlat.
> 
> Another source of real-life deployment of MAP-T:
> https://www.ripe.net/media/documents/Richard_Patterson_-_Sky_Italia_and_MAP-T_-_RIPE_Open_House_2021.pdf
> 
> --
> Best Regards
> Daryll Swer
> Website: daryllswer.com <https://mailtrack.io/l/55060ca61036efef99ea6710fa69c3b8835061de?url=https%3A%2F%2Fwww.daryllswer.com&u=2153471&signature=b58b1a6c25b6d470>
> 
> 
> On Fri, 26 Jul 2024 at 23:13, Kawashima Masanobu(川島 正伸) <kawashimam=40nec.com@dmarc.ietf.org <mailto:40nec.com@dmarc.ietf.org>> wrote:
>>  
>> 
>> Hi Daryll, 
>> 
>> 
>> I won’t argure with this kind of topic. :-) 
>> So, below is just my comment. 
>> 
>> >464xlat is stateful, MAP-T is stateless, 
>> 
>> To be precise, customer side is stateless by CLAT and ISP side is stateful by PLAT. 
>> 
>> >I heavily prefer stateless approaches, why avoid chances to minimise computing overhead in general…
>> 
>> Please don’t focus on ISP side only, we need to think about it in whole system. 
>> MAP-T CE uses more computing overhad than 464XLAT CLAT. 
>> Because MAP-T CE need to perform not only translation but also mapping function. 
>> So, in the whole system, they are more or less the same. 
>> 
>> 
>> Regards,
>> 
>> Masanobu
>> 
>>  
>> 
>> ========================
>> 
>>  NEC Platforms, Ltd.                 
>> 
>>  KAWASHIMA Masanobu             
>> 
>>  kawashimam@nec.com <mailto:kawashimam@nec.com>         
>> 
>>  https://www.necplatforms.co.jp/en/   
>> 
>> ========================
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> From: Daryll Swer <contact=40daryllswer.com@dmarc.ietf.org <mailto:40daryllswer.com@dmarc.ietf.org>> 
>> Sent: Saturday, July 27, 2024 2:07 AM
>> To: Kawashima Masanobu(川島 正伸) <kawashimam@nec.com <mailto:kawashimam@nec.com>>
>> Cc: v6ops@ietf.org <mailto:v6ops@ietf.org>
>> Subject: Re: [v6ops] Re: Traffic control protocols (PCP and UPnP IGD)
>> 
>>  
>> 
>> > Assumed IPv6 mostly network deployment, 464XLAT is the appropriate choice.
>> 
>>  
>> 
>> 464xlat is stateful, MAP-T is stateless, I heavily prefer stateless approaches, why avoid chances to minimise computing overhead in general…
>> 
>>  
>> 
>> There are multiple deployments of MAP-T, some example:
>> https://pc.nanog.org/static/published/meetings/NANOG71/1452/20171004_Gottlieb_Mapping_Of_Address_v1.pdf
>> 
>> 
>> --
>> 
>> Best Regards
>> 
>> Daryll Swer
>> 
>> Website: daryllswer.com <https://mailtrack.io/l/baec0d6aef3bc8f4c1535fab3e5df7e1fa9be865?url=https%3A%2F%2Fwww.daryllswer.com&u=2153471&signature=c906a080c4faa251>
>>  
>> 
>> 
>> 
>> 
>> On Fri, 26 Jul 2024 at 22:17, Kawashima Masanobu(川島 正伸) <kawashimam=40nec.com@dmarc.ietf.org <mailto:40nec.com@dmarc.ietf.org>> wrote:
>> 
>>  
>> 
>> Hi Daryll, 
>> 
>> 
>> >Don't get me wrong, I'm in favour of PCP for only-IPv4 on LTE/5G with 464xlat. 
>> >I'm in favour of PCP for CPE devices for both Dual-Stack IPv4/IPv6 and IPv6-only CPEs (MAP-T).
>> 
>> 
>> I'm in favour of PCP for CPE devices for both Dual-Stack IPv4/IPv6 and IPv6-only CPEs (464XLAT). :-) 
>> Assumed IPv6 mostly network deployment, 464XLAT is the appropriate choice. 
>> 
>> As for firewall control protocol, IMHO, CSA Matter is the appropriate protocol for the future.
>> 
>> Regards,
>> 
>> Masanobu
>> 
>>  
>> 
>> ========================
>> 
>>  NEC Platforms, Ltd.                 
>> 
>>  KAWASHIMA Masanobu             
>> 
>>  kawashimam@nec.com <mailto:kawashimam@nec.com>         
>> 
>>  https://www.necplatforms.co.jp/en/   
>> 
>> ========================
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> From: Daryll Swer <contact=40daryllswer.com@dmarc.ietf.org <mailto:40daryllswer.com@dmarc.ietf.org>> 
>> Sent: Saturday, July 27, 2024 1:20 AM
>> To: Kawashima Masanobu(川島 正伸) <kawashimam@nec.com <mailto:kawashimam@nec.com>>
>> Cc: v6ops@ietf.org <mailto:v6ops@ietf.org>
>> Subject: Re: [v6ops] Re: Traffic control protocols (PCP and UPnP IGD)
>> 
>>  
>> 
>> Kawashima
>> 
>>  
>> 
>> Yeah, that's why I asked if there's ANY application software in the public domain that actually uses PCP. I've never seen one.
>> 
>>  
>> 
>> Don't get me wrong, I'm in favour of PCP for only-IPv4 on LTE/5G with 464xlat. I'm in favour of PCP for CPE devices for both Dual-Stack IPv4/IPv6 and IPv6-only CPEs (MAP-T).
>> 
>> 
>> --
>> 
>> Best Regards
>> 
>> Daryll Swer
>> 
>> Website: daryllswer.com <https://mailtrack.io/l/bfcb5ab50fca7ddb397e36d1b73183be0c56a937?url=https%3A%2F%2Fwww.daryllswer.com&u=2153471&signature=b4d24d1084f8368f>
>>  
>> 
>> 
>> <image001.gif>
>> 
>> On Fri, 26 Jul 2024 at 21:42, Kawashima Masanobu(川島 正伸) <kawashimam=40nec.com@dmarc.ietf.org <mailto:40nec.com@dmarc.ietf.org>> wrote:
>> 
>>  
>> 
>> Hi Daryll,
>> 
>> 
>> Just FYI, in Japan, NTT docomo is using 464XLAT on their 5G network. 
>> However, I’ve never seen PCP implementation. 
>> Press Releases : DOCOMO to Roll Out IPv6 Single-stack Support Beginning Feb. 1 <https://www.docomo.ne.jp/english/info/media_center/pr/2022/0131_00.html>
>> 
>> It is the chiken and egg problem. 
>> If there is no actual app with PCP client, there is no PCP server as well. 
>> We can use PCP on mobile network technically though.
>> 
>> Regards,
>> 
>> Masanobu
>> 
>>  
>> 
>> ========================
>> 
>>  NEC Platforms, Ltd.                 
>> 
>>  KAWASHIMA Masanobu             
>> 
>>  kawashimam@nec.com <mailto:kawashimam@nec.com>         
>> 
>>  https://www.necplatforms.co.jp/en/   
>> 
>> ========================
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> From: Daryll Swer <contact=40daryllswer.com@dmarc.ietf.org <mailto:40daryllswer.com@dmarc.ietf.org>> 
>> Sent: Friday, July 26, 2024 10:51 PM
>> To: Ted Lemon <mellon@fugue.com <mailto:mellon@fugue.com>>
>> Cc: v6ops@ietf.org <mailto:v6ops@ietf.org>
>> Subject: [v6ops] Re: Traffic control protocols (PCP and UPnP IGD)
>> 
>>  
>> 
>> > Anything that uses the APIs on macOS/iOS will work with both upnp and pcp.
>> 
>>  
>> 
>> Good to know. So it's just a matter of the application software making use of already existing APIs on Apple OSes.
>> 
>>  
>> 
>> Ted, does PCP work with LTE/5G? I am not an expert in mobility, but I am curious. If the LTE/5G access network is 464xlat (or maybe MAP-T in the future?), can an application software request the upstream carrier via PCP to open up a port for IPv4, dynamically for temporary IPv4 P2P session to go through? Say VoIP calls without TURN?
>> 
>>  
>> 
>> > Regarding security holes, the question would be, what holes does it create t that aren’t already there with a firewall that allows outbound connections?  I suppose it makes being a DoS attack server slightly easier?
>> 
>>  
>> 
>> Many ISPs have DDoS detection/mitigation/re-routing in place anyway, so if some gets DDoSed (or DoSed), their /32 will be temporarily blackholed or re-routed over a scrubbing infrastructure.
>> 
>>  
>> 
>> I see no issues here, if you want a port open, it'll be open.
>> 
>> 
>> --
>> 
>> Best Regards
>> 
>> Daryll Swer
>> 
>> Website: daryllswer.com <https://mailtrack.io/l/d9660c15f7ba73f852ecacc9dd726a97f16ecaba?url=https%3A%2F%2Fwww.daryllswer.com&u=2153471&signature=fcf70f25da532337>
>>  
>> 
>> 
>> <image001.gif>
>> 
>> On Fri, 26 Jul 2024 at 19:13, Ted Lemon <mellon@fugue.com <mailto:mellon@fugue.com>> wrote:
>> 
>> Anything that uses the APIs on macOS/iOS will work with both upnp and pcp. 
>> 
>>  
>> 
>> Regarding security holes, the question would be, what holes does it create t that aren’t already there with a firewall that allows outbound connections?  I suppose it makes being a DoS attack server slightly easier?
>> 
>>  
>> 
>> Op vr 26 jul 2024 om 06:08 schreef Daryll Swer <contact=40daryllswer.com@dmarc.ietf.org <mailto:40daryllswer.com@dmarc.ietf.org>>
>> 
>> Are there actually any common/popular application software used by people, that supports PCP? I've always only found UPnP and the obsolete NAT-PMP. 
>> 
>> 
>> --
>> 
>> Best Regards
>> 
>> Daryll Swer
>> 
>> Website: daryllswer.com <https://mailtrack.io/l/bd01f399b82a8baf04f66715cc1a7f080a88af17?url=https%3A%2F%2Fwww.daryllswer.com&u=2153471&signature=82a4bd12b2a97f5a>
>>  
>> 
>> 
>> <image001.gif>
>> 
>> On Fri, 26 Jul 2024 at 16:06, Ole Troan <otroan=40employees.org@dmarc.ietf.org <mailto:40employees.org@dmarc.ietf.org>> wrote:
>> 
>> If there is a desire that the IPv6 CE router acts as a firewall, just requiring PCP RFC6887 may not be enough.
>> At least RFC6887 opens up quite a few security trust issues. At least if we have to deal with the threat that an inside client is not under the control of the party interested in security. 
>> Then something like RFC7652 would be required.
>> (Which leads one to wonder if it isn’t simpler to configure this through a UI on the IPv6 CE router instead of a through a protocol…)
>> 
>> Ole
>> 
>> > On 26 Jul 2024, at 03:34, Kawashima Masanobu(川島 正伸) <kawashimam=40nec.com@dmarc.ietf.org <mailto:40nec.com@dmarc.ietf.org>> wrote:
>> > 
>> >  It’s clear now. Thank you.  Regards, Masanobu   From: Ted Lemon <mellon@fugue.com <mailto:mellon@fugue.com>> 
>> > Sent: Friday, July 26, 2024 10:12 AM
>> > To: Kawashima Masanobu(川島 正伸) <kawashimam@nec.com <mailto:kawashimam@nec.com>>
>> > Cc: v6ops@ietf.org <mailto:v6ops@ietf.org>
>> > Subject: Re: [v6ops] Re: Traffic control protocols (PCP and UPnP IGD)
>> >  I think it should be fine to do that, yes. 
>> >  Op do 25 jul 2024 om 17:15 schreef Kawashima Masanobu(川島 正伸) <kawashimam@nec.com <mailto:kawashimam@nec.com>>
>> > 
>> > Ted, 
>> > 
>> > Thank you for your reply.  It’s almost clear now. :-) 
>> > 
>> > How about RFC 6970((UPnP IGD-PCP IWF)? 
>> > It is ‘Standard Track’. Should we mention something? Regards, Masanobu  ========================  NEC Platforms, Ltd.                   KAWASHIMA Masanobu               kawashimam@nec.com <mailto:kawashimam@nec.com>           https://www.necplatforms.co.jp/en/    ========================
>> >    From: Ted Lemon <mellon@fugue.com <mailto:mellon@fugue.com>> 
>> > Sent: Friday, July 26, 2024 8:59 AM
>> > To: Kawashima Masanobu(川島 正伸) <kawashimam@nec.com <mailto:kawashimam@nec.com>>
>> > Cc: v6ops@ietf.org <mailto:v6ops@ietf.org>
>> > Subject: Re: [v6ops] Re: Traffic control protocols (PCP and UPnP IGD)
>> >  As a router vendor, you have more than one set of requirements you need to satisfy. Nobody's saying "don't do uPNP." We're saying "do PCP." We're saying "the IETF is not asking you to do uPNP," not "the IETF is telling you not to do uPNP."
>> >  On Thu, Jul 25, 2024 at 4:50 PM Kawashima Masanobu(川島 正伸) <kawashimam=40nec.com@dmarc.ietf.org <mailto:40nec.com@dmarc.ietf.org>> wrote:
>> > 
>> > Hi all, 
>> > 
>> > > In today’s v6ops meeting there was mention of UPnP. Having a way for client
>> > > devices to signal to network infrastructure what traffic they want to receive is a
>> > > good idea. However, doing that using the UPnP IGD protocol would be a
>> > > disastrously bad idea.
>> > 
>> > I agree with having a way for client devices to signal to network infrastructure. 
>> > However, I'm still not sure UPnP IGD is bad idea. 
>> > 
>> > As you may know, Broadband Forum has released TR-124 issue 9 on July 2024. 
>> > https://rg-device-requirements.broadband-forum.org/index.htm
>> > 
>> > Related parts are as follows. 
>> > 
>> > [WAN.PCP.1] 
>> >  The RG MUST support Port Control Protocol (PCP) Client as specified in RFC 6887
>> > 
>> > [WAN.PCP.7] 
>> >  The RG MUST embed an interworking function to ensure interworking between the UPnP IGD (Internet Gateway Device) used by CPE LAN devices in the LAN and PCP as defined in RFC 6970
>> > 
>> > [MGMT.UPnP.IGD.ACRF.1] 
>> > The RG MUST support UPnP Internet Gateway Device:2 root device. This specification is available for download at http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v2-Device.pdf
>> > 
>> > As one of CE router vendor, what should I do? 
>> > Should I ignore TR-124 because UPnP will be deprecated soon? 
>> > or should we mention UPnP in some form in RFC 7084bis? 
>> > 
>> > As I commented on v6ops WG meeting a while ago, UPnP IGDv2(for IPv6) is increasing in Japan. 
>> > Because our CE router support it, and some gaming title support UPnP controll point as well. 
>> > Syncthing(file sharing app) has also supported UPnP IGDv2. 
>> > Addition to this, we also recognized UPnP IGDv2 implementation increasing in some countries. 
>> > 
>> > Please let me know your opinion. 
>> > 
>> > Regards, 
>> > Masanobu 
>> > 
>> > ======================== 
>> >  NEC Platforms, Ltd.                  
>> >  KAWASHIMA Masanobu              
>> >  kawashimam@nec.com <mailto:kawashimam@nec.com>          
>> >  https://www.necplatforms.co.jp/en/    
>> > ========================
>> > 
>> > 
>> > 
>> > > -----Original Message-----
>> > > From: Stuart Cheshire <cheshire=40apple.com@dmarc.ietf.org <mailto:40apple.com@dmarc.ietf.org>>
>> > > Sent: Friday, July 26, 2024 5:33 AM
>> > > To: v6ops@ietf.org <mailto:v6ops@ietf.org>
>> > > Subject: [v6ops] Traffic control protocols (PCP and UPnP IGD)
>> > > 
>> > > In today’s v6ops meeting there was mention of UPnP. Having a way for client
>> > > devices to signal to network infrastructure what traffic they want to receive is a
>> > > good idea. However, doing that using the UPnP IGD protocol would be a
>> > > disastrously bad idea.
>> > > 
>> > > For a list of the many flaws of UPnP IGD see RFC 6886:
>> > > 
>> > > <https://datatracker.ietf.org/doc/html/rfc6886#section-9>
>> > > 
>> > > This is why the IETF needed to create a robust reliable protocol for doing this, Port
>> > > Control Protocol:
>> > > 
>> > > <https://datatracker.ietf.org/doc/html/rfc6887>
>> > > 
>> > > If an IETF document is going to recommend or require a way of doing this, it should
>> > > be using RFC 6887, both because that is an IETF Standards Track protocol, and
>> > > (more importantly) because of the technical merits of that protocol.
>> > > 
>> > > If the UPnP organization still existed then maybe they could try to design a
>> > > replacement for IGD that works reliably, but what would be the point when the
>> > > IETF has already done that?
>> > > 
>> > > Stuart Cheshire
>> > > 
>> > > _______________________________________________
>> > > v6ops mailing list -- v6ops@ietf.org <mailto:v6ops@ietf.org>
>> > > To unsubscribe send an email to v6ops-leave@ietf.org <mailto:v6ops-leave@ietf.org>
>> > _______________________________________________
>> > v6ops mailing list -- v6ops@ietf.org <mailto:v6ops@ietf.org>
>> > To unsubscribe send an email to v6ops-leave@ietf.org <mailto:v6ops-leave@ietf.org>
>> > _______________________________________________
>> > v6ops mailing list -- v6ops@ietf.org <mailto:v6ops@ietf.org>
>> > To unsubscribe send an email to v6ops-leave@ietf.org <mailto:v6ops-leave@ietf.org>
>> 
>> 
>> 
>> _______________________________________________
>> v6ops mailing list -- v6ops@ietf.org <mailto:v6ops@ietf.org>
>> To unsubscribe send an email to v6ops-leave@ietf.org <mailto:v6ops-leave@ietf.org>
>> _______________________________________________
>> v6ops mailing list -- v6ops@ietf.org <mailto:v6ops@ietf.org>
>> To unsubscribe send an email to v6ops-leave@ietf.org <mailto:v6ops-leave@ietf.org>_______________________________________________
> v6ops mailing list -- v6ops@ietf.org
> To unsubscribe send an email to v6ops-leave@ietf.org



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.