Confusion: why no Filtering behavior type for TCP connection?

[handysome6]

I read about nat type determinatoin method in RFC5780. I found this paragraph in https://datatracker.ietf.org/doc/html/rfc5780#section-3.2

Determining NAT Filtering .... This test applies only to UDP datagrams.

This is the same as the implementaion of this code.

Filtering behavior is not applied in the TCP page.

I am a bit curious about why this is not needed for NAT TCP connections. Is is possible for outside client to establish TCP connection to server that is behind NAT?

[HMBSbige]

Is is possible for outside client to establish TCP connection to server that is behind NAT?

Yes. You can use natmap for example.

why this is not needed for NAT TCP connections.

The standard for TCP is connection-oriented, so it's not possible to send a packet to endpoint A and request a reply from endpoint B.

[handysome6]

Thanks for the quick reply.

natmap is mentioned to provide a good example for establishing TCP/UDP connection to servers that are hidden by NAT. Yet this is only true under the case of Full cone NAT. As defined by modern RFC docs, full cone NAT is the type of NAT that has the following feature:

1. Mapping behavior: Endpoint-Independent Mapping (for internal coming request)
2. Filtering behavior: Endpoint-Independent Filtering (for external coming request)

Only when mapping and filtering behavor are both Endpoint-Independent, can the NAT be called Full-cone, which is required by natmap. https://github.com/heiher/natmap/wiki

However, natmap supports to build both TCP and UDP communications behind NAT. Yes we know full-cone NAT can be used for a internal server to be discovered from outside, but the defination for full-cone was deprecated and replace by new mapping and filtering behavor
So what is the corresponding term for describling TCP's full-cone NAT in this situation?

[HMBSbige]

So what is the corresponding term for describling TCP's full-cone NAT in this situation?

Obviously, since filtering behavior does not apply to TCP, as long as the mapping behavior is Endpoint-Independent, TCP hole punching can be used.