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

[Daryll Swer <[e-mail]>]

> They don't because the underlying firewall or NAT does not support those
protocols.

1. There's no NAT in IPv6.
2. MOST CPEs run Linux Kernel, and Linux Kernel for IPv6 NAT-less, supports
those protocols just fine.

What you call “underlying firewall” is Linux Netfilter framework — supports
DCCP, UDP-Lite, SCTP.

*--*
Best Regards
Daryll Swer
Website: daryllswer.com
<https://mailtrack.io/l/32252de6fc1a94be7c816658a87c618bc423e707?url=https%3A%2F%2Fwww.daryllswer.com&u=2153471&signature=cf50271b178daf9b>


On Sat, 3 Aug 2024 at 04:29, Dan Wing <[e-mail]> wrote:

> On Aug 1, 2024, at 6:45 PM, Daryll Swer <[e-mail]> wrote:
>
>
> The protocol supports other protocols, but I bet most/all implementations
>> do not bother handling anything beyond TCP and UDP.  That's pretty typical
>> for lots of network gear (router ACLs, firewalls, and of course NAT/NAPT).
>> Running over UDP is a long-standing workaround ("solution") for various
>> protocols like IPsec (RFC3948), SCTP (RFC6951), and DCCP (RFC6773).  The
>> overhead of the UDP header is not ideal, but UDP is deployable on the
>> Internet.
>>
>
> Unfortunately, yes. But we are talking about native IPv6, so NAT-related
> hacks and so-called “solutions” (polite word for plaster-fixes) should be
> discouraged.
>
>
> IPv6 residential CPE are encouraged to filter incoming traffic (*) and PCP
> provides a way for those filters to be opened by the host for incoming
> traffic.  PCP is not solely useful for IPv4 NAPT/NAT.
>
> (*) https://datatracker.ietf.org/doc/html/rfc9099#section-5
> (*) https://datatracker.ietf.org/doc/html/rfc6092
>
> I.e. PCP implementations MUST support, at the very least, what's written
> in RFC 6887, section-2.2.
>
>
> They don't because the underlying firewall or NAT does not support those
> protocols.
>
> Interestingly, UDP-Lite (RFC3828) isn't mentioned there, but probably not
> too difficult for an implementation to support both.
>
>
> Sure, it's not difficult.
>
> More ports for UDP+UDP-Lite - Not that it matters for native IPv6, though.
>
>
> -d
>
>
>
>
> *--*
> Best Regards
> Daryll Swer
> Website: daryllswer.com
> <https://mailtrack.io/l/420efa8784d17f20a16b269cb48675ffd728cc77?url=https%3A%2F%2Fwww.daryllswer.com&u=2153471&signature=775f237a6c01c29b>
>
>
> On Fri, 2 Aug 2024 at 00:37, Dan Wing <[e-mail]> wrote:
>
>> On Jul 28, 2024, at 7:01 AM, Daryll Swer <contact=
>> [e-mail]> wrote:
>>
>> I'm all in for PCP signalling to open a port in the stateful firewall as
>> I originally described, and PCP shouldn't encourage locking of the
>> ecosystem to just TCP/UDP, it should support all standardised layer 4
>> protocols (DCCP, UDP-Lite, SCTP, maybe more).
>>
>>
>> https://datatracker.ietf.org/doc/html/rfc6887#section-2.2,
>>    The PCP Opcodes defined in this document are designed to support
>>    transport-layer protocols that use a 16-bit port number (e.g., TCP,
>>    UDP, Stream Control Transmission Protocol (SCTP) [RFC4960], and
>>    Datagram Congestion Control Protocol (DCCP) [RFC4340]).  Protocols
>>    that do not use a port number (e.g., Resource Reservation Protocol
>>    (RSVP), IP Encapsulating Security Payload (ESP) [RFC4303], ICMP, and
>>    ICMPv6) are supported for IPv4 firewall, IPv6 firewall, and NPTv6
>>    functions, but are out of scope for any NAT functions.
>>
>> The protocol supports other protocols, but I bet most/all implementations
>> do not bother handling anything beyond TCP and UDP.  That's pretty typical
>> for lots of network gear (router ACLs, firewalls, and of course NAT/NAPT).
>> Running over UDP is a long-standing workaround ("solution") for various
>> protocols like IPsec (RFC3948), SCTP (RFC6951), and DCCP (RFC6773).  The
>> overhead of the UDP header is not ideal, but UDP is deployable on the
>> Internet.
>>
>> -d
>>
>>
>