everyone---
Okay, the Apple IS&T argument for wanting to use ULA and not PI for
B2B extranet communication goes like this:
+ we expect to have public-facing servers at PI addresses;
+ some services at these servers still need to be reachable
over the public Internet from B2B partner hosts;
+ those hosts may also be authorized separately to use the
extranet link for access to other services at these servers;
+ some services on these servers may need to be reachable
separately over either path, as named;
+ if we inject routes to our PI space to our partner networks,
then *all* the traffic from partner hosts to our public-
facing servers goes over the B2B extranet, not just that for
specific services. We don't want that.
Summarizing. When partner hosts connect to server.apple.com at
2620:0:1b00::SERVER, the traffic should go over the public Internet.
When those same partner hosts connect to server.apple.com.b2b-
extranet.example.com at $ULA::SERVER, the traffic should go over the
private link. Likewise, we need the same to happen when our hosts
communicate with server.example.com and server.example.com.b2b-
extranet.apple.com at the corresponding PI/PA and ULA addresses.
Quoting my IS&T contact again:
I believe our 3 choices are:
1) Inject PI address into partner (and vice versa)
2) Inject ULA address into partner (and vice versa)
3) NAT at the partner connection
#1 is broken because the hosts might need to talk to other partner/
Apple services via another path
#2 is dangerous because it dramatically increases the routing table
size.
#3 does break end-to-end IPsec AH. (not a large impact from my
standpoint)
What I infer that he means by "2) inject ULA address into partner (and
vice versa)" is this: route ULA prefixes alongside PI prefixes
throughout the enterprise to every network where B2B servers exist
(potentially anywhere/everywhere) and aggregate those together into
one or more ULA /48 prefixes to be injected into the partner network.
They'd prefer to conserve router table space, by routing only the PI-
space addresses throughout the enterprise, then apply some kind of
symmetric IPv6 NAT at the B2B extranet gateways. They *do* care that
IPsec AH is broken by this, and it *does* bother them that
applications need to be NAT-friendly to work over the extranet link,
but their calculation is that they're much more worried about
conserving the router table space than they are about making
application protocols jump through NAT hoops.
Whenever an enterprise router upsets because its table memory exhausts
on an update, it can take out a whole building. That tends to be very
painful for the IS&T staff. They're *VERY* sensitive to such risks.
This is why it doesn't help to use PI or PA space on the extranet
instead of a ULA claim. Either way, we still have the same load on
the routing tables, but the former means consuming twice as much
global space. Also, it's worth noting that using PA space instead of
ULA space means having to renumber the extranets when changing
providers. Using a symmetric IPv6 NAT avoids all that in one fell
(and I do mean fell) swoop: interior routing tables are minimal in
size because they only carry our PI/PA routes, *and* the B2B extranet
addressing is independent of the PI/PA space addressing for the public-
facing services.
I don't think there's anything in RFC 4864 to address this perception
of address translation. It's not really a "local network protection"
method, is it? It's a "local operational risk mitigation" method.
Now, it occurs to me that enterprise routers and interior routing
protocols could be optimized for carrying a dual aggregation around at
the same or near the same cost in router table space as operating a
singularly aggregated routing domain, but I don't think we've tried to
do that. Have we?
--
james woodyatt <[email protected]>
member of technical staff, communications engineering
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
