On Apr 9, 2009, at 14:07, Brian E Carpenter wrote:
On 2009-04-09 03:22, james woodyatt wrote:
On Apr 7, 2009, at 20:02, Brian E Carpenter wrote:
(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.
[...] Well, I believe that IT managers will need to get over that
concern. [...]
I told them that IETF will likely try to address that concern by
saying something along the lines of... Buy Enough Hardware To Meet
Your Needs. My contact called that a "vendor-centric" view of the
world, and they proceeded to explain to me how that wasn't a realistic
way to look at their issues.
That was before I elaborated my point about NAT breaking address
referrals for applications that otherwise might be using them quite
successfully on the public Internet now that IPv6 has sufficient
address space to support them. I am, however, not optimistic that I
have changed their minds yet-- it's much harder to quantify the risk
of investing in an infrastructure that makes tomorrow's applications
prohibitively expensive and locks the company into using today's
applications long past their expiration date. The other side of that
risk, i.e. over-investing in gear that we won't need if tomorrow's
applications never arrive, has very tangible numbers stamped on it.
[...] except for sites large enough to have a PI prefix anyway,
which makes the problem go away without needing multiple prefixes.
The whole complex of problems we're discussing really only arises
for sites too small to get a PI prefix, and it's hard to imagine
them being short of space for their IGP tables.
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.
Furthermore, now is probably a good time to note what my IS&T contact
told me 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'm given to understand that official
communications to that effect have already been sent to several
vendors, but I have not seen them.
--
james woodyatt <[email protected]>
member of technical staff, communications engineering
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
