On Mar 10, 2009, at 16:23, Fred Baker wrote:
For the record, the issues with NAT came, and it was not on the
standards track. It wasn't initially even documented in an RFC.
Trying to kill the discussion isn't going to kill the concept.
===== <rant> =====
While I'm up on this soapbox now, let me just state for the record
that I don't believe for a nanosecond that standards-track NAT66 will
serve as anything but encouragement for people like my own engineering
management to go "all the way" and implement NAPT66.
Please, I ask for forebearance to explain.
FWIW, I've been officially asked on more than one occasion about the
viability of NAPT66 (not NAT66, about which nobody else at Apple seems
to care), and the discussion on this BOF list has not made me feel
safe resisting calls to implement it.
Has anyone else here read the Slashdot forums any time the subject of
IPv6 comes up? They're packed to the rafters with people who think
the IETF is nuts for not making NAPT66 into a standard five years
ago. It's not much better on my employer's own discussion support
forums. Need I point out the *OG lists? I have been arguing down
enhancement requests for NAPT66 functions in our products for as long
as they've had an IPv6 routing feature, and I don't know how much
longer I can keep standing up in the wind. And frankly, I don't plan
to do so anymore.
NAPT66 would really only be a little bit worse than NAT66. Just a
tiny little bit. Really.
And: people think they want it. They might be willing to pay money
for it at some point, if IPv6 becomes something people want to pay
money for... so, why shouldn't I just give up on DHCP6-PD altogether
and learn to love the NAPT66?
Please, help me explain to my management, and by extension our
customers, the teeming hordes on Slashdot and our discussion forums,
why I shouldn't just turn on the NAPT66 code and give them what they
really think they want. Because I completely fail to see it at this
point. Yes, it breaks end-to-end reachability, but so does their
stateful packet filter we turn on by default. Yes, it breaks end-to-
end addressability, but not really any worse than the NAT66 standard
that everyone will soon be deploying everywhere at once, because
honestly, who cares that NAT66 lets you manually provision the DNS
with pre-translated AAAA records?
So, why should I continue resisting? My managers don't think we need
NAT66. They think that if we're all going to be dealing with
ubiquitous IPv6 address translation anyway, then *NAPT66* in our
products will be easier to implement and involve less technical and UI
risk for us. And they're right. How do I convince them that NAT66 is
worth the extra energy?
===== </rant> ====
--
james woodyatt <[email protected]>
member of technical staff, communications engineering
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
