[arin-ppml] IPv6 Non-connected networks

[Owen DeLong]

On Mar 29, 2010, at 7:39 AM, Chris Engel wrote:

> Owen DeLong wrote:
> 
>> You are assuming a lot more about human behavior by less
>> qualified individuals than is required in my assertion that
>> people should properly configure their firewalls. If I have
>> to tolerate NAT and it's damage because you can't reliably
>> avoid mistakes that fail open on your firewalls, then, you
>> need to allow for a way to reimburse my costs that come from
>> your even less qualified end users that also happen to be my
>> customers.
> 
> 
> Owen,
> 
> Who am I to tell you how to bill your customers? If you want to bill some sort of "NAT surcharge" into your fees or (a probably more reasonable way to recoup costs) charge support by the minute/hour then go for it if your business model supports it. I certainly don't tell you how to bill.
> 
Again, you miss my point.  If you implement NAT, and, it causes problems for my customers that costs me time (==money) to troubleshoot, I want a way to recover those costs from you, the person who inflicted the damage, not my customer who is an innocent bystander/victim of your NAT choices.

> However, I don't see how that situation is any different then supporting a customer who isn't technicaly profficient ("um... what's my IP address? A command prompt...what is that?") or speaks slowly, or maybe has a language barrier...or maybe has something else going on thier network that interferes with your equipment.... all of which would cause you more time/effort in support then you would ordinarly need to (I've done plenty of support calls in my day). Should none of those people be allowed use of the internet because they would cost more support time then others?
> 
The idea of distinguishing between that which cannot be helped (the scenarios you describe in the above paragraph) and willful acts of destruction (NAT) is not a new concept. Generally, the law tends to hold that liability is created only in the latter case.

> 
> Furthermore, I would think the answer to your situation would be rather straightforward. If you are the designer of the equipment/software that you are working with... why wouldn't you design in a special diagnostic mode on your phone that sent out a unique number/code for the particular phone issued to that customer inside each packet sent....and then build a tool that could work with a packet sniffer to examine the packets you were recieving to see if any of them corresponded to that phone? That should tell you definitively whether you were getting any of those packets regardless of what was happening with the packet headers (and presumably even independant of whatever protocol they might be running under).
> 
1.	You are assuming I control the design/manufacture of the CPE. I'm talking about something more like a SIP-based service (BYO-hardware).
2.	You are assuming I want to design/manufacture/sell hardware. I don't, I want to sell services based on existing standards.

> Turning the arguement around on you... why should NAT be disallowed on the entire internet simply because you can't be bothered to build in more robust diagnostic tools on the equipment that you want to sell?
> 
I'm not trying to sell equipment, I'm trying to sell service based on existing standard protocols.  Why should people trying to do that have to redesign their equipment and services because you want to use NAT?

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100329/3a6a5e81/attachment.htm>