Re: Generic anycast addresses...

[Mikael Abrahamsson <[e-mail]>]

On Fri, 31 May 2019, Ted Lemon wrote:

> On May 31, 2019, at 2:11 AM, Mikael Abrahamsson <[e-mail]> wrote:
>> https://tools.ietf.org/html/rfc6052#section-2.1 <https://tools.ietf.org/html/rfc6052#section-2.1> , the 64:ff9b::/96 prefix for NAT64, out of global scope. However, you typically need the traffic to only hit one of these (because of state), so I guess they will not be BGP anycasted.
>
> That’s a similar idea, but not anycast.  There you’re hoping the packets 
> reach an edge router that does NAT64.  So a lot of the work in the 
> infrastructure is the same—if you have the server at the edge and only 
> one egress, you don’t really have to do anything except make sure that 
> the edge router forwards the packet to the right host.  If you want 
> something fancier, you set up the right route—in the case of 64:ff9b, if 
> you want your NAT to be somewhere other than the edge, you just arrange 
> your internal routing so that the packets get to the network address 
> translator.  You could do the same thing for these anycasts.
>
> One disadvantage of allocating well-known anycast addresses out of the 
> same address is that if your anycast servers are actually in different 
> places, you need to have host routes in your routing fabric, or use 
> tunnels, so that’s a downside that doesn’t exist for the NAT64 WKP.

I also forgot to mention: 
https://tools.ietf.org/html/draft-ietf-mboned-driad-amt-discovery-06

This one uses SRV records to find the relay.

-- 
Mikael Abrahamsson    email: [e-mail]