Mailing List Archive

Multiaddressing Intent and Practicality
This is a question about multihomed systems, systems attached to multihomed
networks, or systems providing services to both public and private
resources.

I'm considering a scenario that looks like this[1], where a multihomed HQ
has unique PA /48s and delegates them throughout the enterprise. The HQ
network admins deploy a pair of /56s per remote site, each prefix coming
from a different provider. This may be a bad assumption and I'm asking for
help.

What does a public service hosted at site 4 look like? If I query the AAAA
record, do I get a pair of addresses and DNS round robin them in the
classic way? Are there well defined best practices for this kind of thing
to ensure availability? How does this support resilient services? I want my
webserver to be accessible during ISP failure. DNS round robin doesn't do
that. It requires intervention to update the record and restore service.

What if I change the diagram a bit, like this[2]? In this case the Private
WAN subnet is not publicly advertised. My remote sites want to talk to the
web server. My web server also wants to be publicly accessible. My web
server now has two addresses and two AAAA records, one public and one
private. Is this how IPv6 multiaddressing is intended to be used?

What is the routing behavior for source address selection in the second
case? How does the web server know to talk to the internet using its public
address and site to site using its private address for connections it
initiates? Are these things clearly defined and figured out in literature
and BCPs? Do we really rely on host based routing and security in IPv6
rather than transit nodes?

[1]https://i.imgur.com/Jzvj2sz.png

[2]https://i.imgur.com/XB416tT.png

Jason
Re: Multiaddressing Intent and Practicality [ In reply to ]
Hi Jason,

You might consider taking this discussion also to v6ops@ietf.org. I guarantee you would get a full set of answers to choose from ;-). More below...

On 06-Aug-22 00:16, Jason Iannone wrote:
> This is a question about multihomed systems, systems attached to multihomed networks, or systems providing services to both public and private resources.
>
> I'm considering a scenario that looks like this[1], where a multihomed HQ has unique PA /48s and delegates them throughout the enterprise. The HQ network admins deploy a pair of /56s per remote site, each prefix coming from a different provider. This may be a bad assumption and I'm asking for help.
>
> What does a public service hosted at site 4 look like? If I query the AAAA record, do I get a pair of addresses and DNS round robin them in the classic way? Are there well defined best practices for this kind of thing to ensure availability? How does this support resilient services? I want my webserver to be accessible during ISP failure. DNS round robin doesn't do that. It requires intervention to update the record and restore service.

The classical answer is get your own PI /48 from the RIR and have both ISPs announce it. The alternative is to persuade each ISP to announce both the PA /48s. If they are doing ingress filtering (https://www.rfc-editor.org/info/bcp84) they have to allow each other's /48.

> What if I change the diagram a bit, like this[2]? In this case the Private WAN subnet is not publicly advertised. My remote sites want to talk to the web server. My web server also wants to be publicly accessible. My web server now has two addresses and two AAAA records, one public and one private. Is this how IPv6 multiaddressing is intended to be used?

Split horizon DNS is pretty common for this sort of reason. You can consider using a ULA prefix (RFC 4193) for internal use, although it isn't required.

>
> What is the routing behavior for source address selection in the second case?

Longest match should work out all right.

> How does the web server know to talk to the internet using its public address and site to site using its private address for connections it initiates?

RFC 6724 should take care of that, if you set the precedence entries up correctly. How to do that is o/s dependent, unfortunately. (Except that there's a current IETF discussion on making that work properly with ULA addresses: https://www.ietf.org/archive/id/draft-ietf-v6ops-ula-00.html)

> Are these things clearly defined and figured out in literature and BCPs? Do we really rely on host based routing and security in IPv6 rather than transit nodes?

I'm not sure what you mean there, but IPv6 does *not* rely on NAT. Firewalls and ACLs work of course.

Hope this helps, but probably some other people will amplify.

Regards
Brian Carpenter

>
> [1]https://i.imgur.com/Jzvj2sz.png <https://i.imgur.com/Jzvj2sz.png>
>
> [2]https://i.imgur.com/XB416tT.png <https://i.imgur.com/XB416tT.png>
>
> Jason