I agree with John's analysis of the constraints here. It may be possible to get the ISPs to move on the expectation that if they do nothing government coertion will follow. The caveat here being that the pressure the vendors are most likely to be responsive to would be from the US and it is not likely that the ISPs would become concerned about iminent regulatory changes from an outgoing administration, particularly since uniquely in recent history there is no expectation that a sitting President or Vice President will be on the ballot in 2008. The ISPs face costs from bots on their nets, so there is a direct cost benefit. I don't think that the game of charging to eliminate caps would be viable for devices other than a cable/dsl modem rented from the ISP. That approach would introduce a harmful oppositional dynamic with the slashdot crowd. At present I would be happy to simply stop the problem getting worse by getting such measures introduced into legacy gateways. Turnover of the legacy base is somewhat harder. One thing that I have found personally is that the WiFi hardware currently supplied is poorly made and not fit for 24/7 operation. The devices overheat in hot weather, the WiFi service definitely degrades over time. I have a box full of deceased brand name routers. If my experience is representative we don't need to worry much about turnover. Otherwise what I would try to do to drive turnover would be to tie the security (bot capping) and future proofing (IPv6 transistion management) to a branding campaign that provides the user with a tangible direct benefit, vis peer-to-peer video conferencing 'just works' and administration issues 'just work'. We agree at the requirements level here: peer to peer video conferencing must work seamlessly. The difference is that I am prepared to require the applications to make adjustments to allow for the deployment of NAT while you appear to be insisting on a particular means of achieving that requirement. > -----Original Message----- > From: John C Klensin [mailto:john-ietf@xxxxxxx] > Sent: Wednesday, March 07, 2007 9:09 AM > To: alh-ietf@xxxxxxxx > Cc: ietf@xxxxxxxx > Subject: RE: NATs as firewalls > > (off list) > > --On Tuesday, 06 March, 2007 15:46 -0800 Tony Hain > <alh-ietf@xxxxxxxx> wrote: > > > While I agree with Brian that the enterprise draft will be > difficult, > > I also believe the SOHO one will be virtually impossible to get > > agreement over. > > I agree, although I think we might disagree a bit about the > reasons. On the other hand, I also think that a serious IETF > (or other) effort to try to define such a thing would have > value, even if it only produced an info document about why > the problem is hard and what the issues are before failing > and collapsing. > > > The issue is that most ISP's > > don't yet get the point that the device needs to be dual managed, > > because they are still in the mindset that there are just a > couple of > > devices behind each customer nat at most and very little > change to the > > configuration over time. > > Hmm. Unless the economics of ISPs who deliver services to > residences and SOHO setups have changed _very_ significantly > since I was last deeply immersed in those very confidential > numbers, no one is doing any real remote management regardless > of what Phillip considers appropriate or necessary. One could > imagine ISPs able to download new images that were the same > for everyone, but the margins just aren't there for anything > other than the "everyone gets the same boundary config and > you can put whatever you like behind it" or "if you fuss with > this, it is your problem" arrangements that are prevalent today. > > My guess is that the economics would support a device that > combined a cable modem or DSL box with some significant > inbound and outbound firewall capabilities, including the > ability to do some rate-limiting, reasonable control over > ICMP as well as TCP and UDP and probably some real-time > protocol. I'd expect that box to be delivered to the > customer either fully locked up or configured at setup time > with any new configuration requiring > payment of a separate fee. If I were designing one of these, > I think I'd put a couple of flash memory slots in it (SD or > whatever one prefers) that could be used to reimage or reprogram > the box or give the customer more control. They wouldn't do > anything that could not, in principle, be done over the net > but the idea of sending the customer off to _pay_ for an > unlocking function or some other set of functions and then > receiving a key would, I think, be a lot more plausibly > marketable than paying for something that appears to be less tangible. > > And that is the answer to Phillip's concern about what to do > about old hardware too. Just as Verizon sent me a letter > last week that said that I'd better have a plan about getting > rid of any analog-capable mobile phones I might still have, > the ISPs, if backed by either judicial or government > pressures (which I believe to be necessary to accomplish > anything) could easily put out a note that says "a reasonable > level of protection for the network from you is now > necessary. That can be done in two ways. One is to upgrade > your box, which will also give you the capability of > obtaining fewer restrictions. The other is that we do it > centrally, which will give you a very restricted environment > (but not so restricted as to have impact on the typical > residential user), and we will charge you a fee for it." > > > FWIW: nat has not slowed the consumption of IPv4 addresses > enough to > > be the panacea people keep hoping for. It is clear that > most network > > managers are going to do squat until there is a crisis to force > > action. That will occur sometime after 2010 when they need > more than > > they already have and find that the lease price per IPv4 > address per > > day has been moving up from its current averages of $1/day > or $5/day > > depending on contract length (a price service providers > seem to have > > no trouble collecting while the addresses are still Free > from IANA). > > For those who wonder about the date see: > > tndh.net/~tony/ietf/IPV4-pool-combined-view.pdf > > Agreed, but we have had this discussion before. And I am in > strong agreement that the perception of crisis --either of > the type you identify here or of a serious threat of > regulation or litigation as above-- is the only thing that is > likely to create actual motion. If nothing else, the margins > are just too small to do anything "because it is good" if it > drives up costs even to the extent of a few training courses > for support staff. > There will need to be something, almost certainly external, > that can be blamed as a reason for introducing disruption, > forcing new hardware, or increasing costs (probably all three > in practice). But, if we can predict something happening, > under any scenario about cause, the time for the IETF to get > started on its part of the job is "soon" or even "now", not > after the crisis occurs and everyone starts running off in > their own directions because no one has pointed the way. > > john > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf