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.
Thanks!
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps