On Feb 19, 2008, at 11:50 AM, Iljitsch van Beijnum wrote:
However, in much of the world, profit margins for ISPs in the
residential and SOHO business are sufficiently thin that a
single support call can wipe out a few month's of profits from
that account and one that actually requires getting someone with
knowledge on the phone can wipe out a year or more.
And you think this works in FAVOR of NAT?
The whole point of avoiding support calls is that everything works
without trouble in the first place. Telling someone how to type in a
URL to get at their device configuration is something you should avoid
at almost any cost, because best case, it wastes time, worst case the
user simply can't do it. I'm not kidding here.
My current ISP (who forces me to use IPv4 NAT) lets me manage my port
mappings through their website. Much smarter: if I were to call them,
they could easily look inside their own system and fix things, rather
than tell me to go into the box and do it.
DY> Yes, you will undoubtedly get better customer service from ISPs
who provide management of the SOHO endpoints (whether or not that is
through a "managed services" offering or just their default
operational style). I would expect most smart ISPs are moving in
that direction. But there will certainly be those out there who don't.
DY> For those who don't manage the remote router/gateway, having an
identical address pool for each location could be a useful way to
minimize support issues.
DY> Forgetting about ISPs, for a moment, let's think about equipment
vendors. If you think of all the zillion Linksys (or D-Link or
whomever) home gateways... all of which are probably using
192.168.0.1 or whatever is the default address block. The fact that
they are all identical makes *their* technical support issues much
easier to address. And in this case they probably have no way to
manage those devices remotely.
See the aside below, but, if our recommendation for moving from
IPv4 to IPv6 involves training a user who has gotten used to
typing, e.g., "http://10.0.0.5";, or maybe just "10.0.0.5", to
type http://[fc00::1]/"; we will have inserted another stumbling
block on the way to IPv6 deployment.
Hence the need for a decent service discovery mechanism.
I was merely illustrating the fact that there are MANY ways to arrive
at the desired result that do not require NAT. They're not all
especially great, but so far, nobody has been able to show how having
NAT makes this better. Without service discovery or a DNS or external
connectivity, you would still have to type a URL like above.
DY> I don't know that any of us are saying that "having NAT makes
this better". I'm saying that having NAT is a *reality* in the
corporate network environment and I personally expect that it will
continue to be used in those environments after the IPv6 transition.
(For reasons I've previously expressed.)
DY> So, in my view, the IETF has the option of addressing how to
properly do NAT for IPv6 for those people out there who may wish to
do so - or NOT addressing IPv6 NAT and letting equipment vendors and
customers make it up as they go along.
Regards,
Dan
--
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO Voxeo Corporation dyork(_at_)voxeo(_dot_)com
Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com
Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com
Bring your web applications to the phone.
Find out how at http://evolution.voxeo.com
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf