Thanks, I added trhese as issues #1054-1057, so we don't forget these
topics.
... I also have one specific query below...
On 05/08/2022 12:01, Fernando Gont wrote:
Folks,
Some comments/feedback on the aforementioned I-D:
* Section 4.2.1.1. Local Endpoint candidates
You should probably consider PCP/UPnP here. see e.g.
https://www.ietf.org/id/draft-gont-v6ops-ipv6-addressing-considerations-02.html#name-support-for-firewall-traver
* Section 4.3.3. Failover
I haven't recently checked what's the status of current TCP
implementations. But at least at some point in time there are some
that would failover more quickly based on notifications from the
network (e.g., ICMP errors). see:
https://datatracker.ietf.org/doc/html/rfc5461
Section 4.7:
4.7. Implementing listeners When an implementation is asked to
Listen, it registers with the system to wait for incoming traffic to
the Local Endpoint. If no Local Endpoint is specified, the
implementation should use an ephemeral port.
Note: there are implications of using a port number from the ephemeral
port range. See e.g. Section 3.1 of
https://www.rfc-editor.org/rfc/rfc6056.html#page-8
TL;DR; The general idea is that one should use the same range to pick
port for outgoing connections than to pick ports for listening endpoints.
If the Selection Properties do not require a single network
interface or path, but allow the use of multiple paths, the Listener
object should register for incoming traffic on all of the network
interfaces or paths that conform to the Properties. The set of
available paths can change over time, so the implementation should
monitor network path changes, and change the registration of the
Listener across all usable paths as appropriate. When using multiple
paths, the Listener is generally expected to use the same port for
listening on each.
I'd probably stress this a bit more e.g., quite often the port needs
to be registered somewhere (e.g., directory service), so having
different ports for each interface would seem problematic.
Section 4.7.2.:
On platforms with facilities to create a "virtual connection" for
connectionless protocols implementations should use these mechanisms
to minimise the handling of datagrams intended for already created
Connection objects.
I don't necessarily disagree, but you should probably elaborate here
-- e.g., on one hand, "stateless" is good in the sense that you don't
tie system resources unnecessarily. However, it's also more prone to
spoofing, to the extent that an attacker might require "a lot of work"
from a server without even proving that it can receive the return
packets.
I'm not quite sure what you are asking here. What I think was intended
was very similar to the way UDP sockets in BSD can be used with
"connect", is there something else you were expecting to see in the text?
Thanks!
Cheers,
Gorry
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
