On 06/26/2018 09:08 PM, Sowmini Varadhan wrote:
On (06/26/18 21:02), Ka-Cheong Poon wrote:
In this case, RFC 6724 prefers link local address as source.
the keyword is "prefers".
There is a reason for that. It is the way folks expect
how IPv6 addresses are being used.
While using non-link local address (say ULA) is not forbidden,
doing this can easily cause inter-operability issues (does the
app really know that the non-link local source and the link
local destination addresses are really on the same link?). I
think it is prudent to disallow this in RDS unless there is a
very clear and important reason to do so.
I remember the issues that triggered 6724. The "interop" issue
is that when you send from Link-local to global, and need forwarding,
it may not work.
It is not just forwarding. The simple case is that one
picks a global address in a different link and then
use it to send to a link local address in another link.
This does not work. And the RDS connection created will
be stuck forever. I don't think this is a good idea to
have such stuck connections.
but I dont think an RDS application today expects to deal with
the case that "oh I got back and error when I tried to send to
address X on rds socket rs1, let me go and check what I am bound
to, and maybe create another socket, and bind it to link-local"
I don't expect RDS apps will want to use link local address
in the first place. In fact, most normal network apps don't.
You're not doing this for IPv4 and RDS today (you dont have to do this
for UDP, afaik)
Do you know of any IPv4 RDS app which uses IPv4 link local
address? In fact, IPv4 link local address is explicitly
disallowed for active active bonding.
This is especially true if "X" is a hostname that got resovled using DNS
Can you explain why DNS name resolution will return an IPv6
link local address? I'm surprised if it actually does.
BTW, if it is really > needed, it can be added in future.
shrug. You are introducing a new error return.
An error needs to be returned because it is not allowed.
--
K. Poon
ka-cheong.p...@oracle.com
