https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292807
Patrick M. Hausen <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from Patrick M. Hausen <[email protected]> --- I researched a similar problem concerning NAT port forwarding in IPv6. RFC 4291 states: ------- 2.5.3. The Loopback Address The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. It may be used by a node to send an IPv6 packet to itself. It must not be assigned to any physical interface. It is treated as having Link-Local scope, and may be thought of as the Link-Local unicast address of a virtual interface (typically called the "loopback interface") to an imaginary link that goes nowhere. The loopback address must not be used as the source address in IPv6 packets that are sent outside of a single node. An IPv6 packet with a destination address of loopback must never be sent outside of a single node and must never be forwarded by an IPv6 router. A packet received on an interface with a destination address of loopback must be dropped. ------- which I assume is the reason for this: https://cgit.freebsd.org/src/tree/sys/netinet6/ip6_input.c#n782 The kernel seems to refuse to send any packet with ::1 as the source if the destination is not also the loopback interface. I wonder if this (the RFC requirement) is really something that needs to be enforced that low in the code. In IPv4 you can easily bind a service to 127.0.0.1 so you get a stable socket that won't go away when an interface goes down. Then configure NAT port forward from any interface to that loopback address to actually access the service. That will lead to any reply packet with a source of 127.0.0.1 to be NATed back to a proper address. Wy does the system not permit me to do the same for IPv6? The operator can enforce via configuration that a packet with source ::1 never makes it out of the system. It need not be blocked by the kernel. Inbound NAT is a finde solution to a real problem. Just my 2 ct. Kind regards, Patrick -- You are receiving this mail because: You are the assignee for the bug.
