On Apr 7, 2009, at 20:02, Brian E Carpenter wrote:
On 2009-04-08 10:51, james woodyatt wrote:...
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)
I think this is FUD. I'd like to understand why it would be
'dramatic'. [...]
(Of course, there's no doubt that if you're running multiple
prefixes, according to the IPv6 standard model, your IGP will have
to carry multiple routes accordingly. But that's another discussion.)
As I mentioned later in the same message, I think that's the "dramatic
increase" they're talking about and it seems to be the core issue for
them.
In my reply, I wrote this:
Keep in mind that #3 breaks more than just IPsec authenticated header.
It also breaks all applications that do referrals by address instead
of by name. These aren't very common in IPv4, because of the
ubiquity of NAT deployments today, but you have to expect they will
be *much* more common in IPv6, where there will be far fewer, if
any, NAT deployments hindering address referrals.
If you choose not to deploy sufficient routing capacity to carry
both the PI/PA and the ULA routes throughout Apple, then you're
making the cost of upgrading all of Apple's enterprise routers into
the barrier against deploying the very first application to come
along that requires address referrals to work over the B2B extranet
just like they already do on the public Internet. Do you know what
application that might turn out to be? I don't, but I hope for your
sake that it isn't something business-critical, with an impossible
deadline from senior executives, implying the need to roll out
service overnight at ULAs to every site in the Apple network.
I'm awaiting a response.
--
james woodyatt <[email protected]>
member of technical staff, communications engineering
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
