Re: ISP support models Re: IPv6 NAT?

[Dan York <dyork@xxxxxxxxx>]

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@xxxxxxxxx

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@xxxxxxxx
http://www.ietf.org/mailman/listinfo/ietf