Re: Generic anycast addresses...

[Michael Richardson <[e-mail]>]

Mikael Abrahamsson <[e-mail]> wrote:
    >> https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-00

    > I have now read RFC1546 and now I understand some of the confusion. Did the
    > concept of "send SYN to anycast address and get SYN-ACK back from actual
    > unicast address" ever get implemented anywhere?

I don't think so.
Maybe some BSD 4.0 could support it, but it would be fly in the face of most
firewalls.  It would rely only on the sequence number to match things up.
That would be pretty weak, particularly at the time RFC1546 was published!

If IPsec was ubiquitous in the way imagined once, I believe that we could
make IKEv2 to anycast, respond from unicast work well securely enough.
If well integrated with the stack, the SYN would go out with the correct
unicast destination learnt from IKEv2.  Alas, IPsec is not ubiquitous like
this :-(

    > Now, if we're going to do the whole "functional anycast addresses", is the
    > expectation that it's going to add the example RFC1546 behaviour for TCP
    > sessions, thus needing changes to all stateful L4 protocols in the host
    > stack? That's a huge change, and I'm pretty sure the security requirements
    > section would be huge? If not, what does the whole scoping actually add? What
    > does all this information actually add over well-known addresses out of
    > regular unicast space that we're already using?

It means that we can effectively drop them when they get to the edge of the
scope.   It means that a scoped anycast can be used in the home network for
something, and then *also* used at the ISP for a similar use without
confusing things.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-