On Apr 9, 2009, at 16:50, Brian E Carpenter wrote:
On 2009-04-10 09:53, james woodyatt wrote:
...
Actually, a PI prefix doesn't make the problem go away. Apple has
a PI prefix now: 2620:0:1b00::/45, and our IS&T managers are
*still* planning to deploy IPv6/NAT boxes to facilitate separation
of traffic for public-facing services and B2B extranet services.
Sigh. It defeats me why people believe this will create less admin
work and less likelihood of errors than a set of ACLs in the border
routers.
It's the multiple prefixes thing, of course. That, and the ongoing
related worries, perhaps not entirely rational, about possible
unexpected side effects of default address selection. They think
having just one set of prefixes to route through the enterprise will
be a lot simpler and much less prone to administrative error. I
can't, of course, argue about that-- I simply don't know.
[...] about NAT66's constraint of /48 for the maximum prefix length
for the NAT range: it's unacceptably short, and they're insisting
that vendors need to have an IPv6/NAT solution that operates with
prefixes up to /64 at minimum. [...]
I fully agree that /64 is needed. The IPv6 addressing architecture
really leaves no choice on that.
There was also some grousing when I mentioned that we don't think
address amplification is a worthy goal for any new 6AI standards
effort. They've grown quite accustomed to using asymmetric
translation to conserve address space in various parts of their
network, and they're worried that its lacking in NAT66 will be a
source of additional headache for them.
They really like their NAPT gateways, and the thought of planning to
go without them into combat leaves them far, far away from their happy
comfort zone. I wish I knew how to soothe their nerves.
--
james woodyatt <[email protected]>
member of technical staff, communications engineering
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
