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. 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.
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 Tony > -----Original Message----- > From: Brian E Carpenter [mailto:[EMAIL PROTECTED] > Sent: Monday, March 05, 2007 2:44 AM > To: John C Klensin > Cc: ietf@ietf.org > Subject: Re: NATs as firewalls > > John, > > (after also reading Michael's response) > > I don't disagree. I think there is scope for writing a list of > desirable properties for SOHO routers in the light of these > various inputs. I'm less certain it can be done for enterprise > boundary routers. But it would be a tricky and contentious job > in both cases. Even draft-ietf-v6ops-nap took many moons > and several major editing passes, and it only starts the work. > > Brian > > On 2007-03-04 22:39, John C Klensin wrote: > > > > --On Sunday, 04 March, 2007 20:05 +0100 Brian E Carpenter > > <[EMAIL PROTECTED]> wrote: > > > >> Michael, > >> > >> On 2007-03-02 16:19, [EMAIL PROTECTED] wrote: > >> ... > >>> No real disagreement here but I do see a way forward. First, > >>> clarify the terminology. Second publish a pair of RFCs rather > >>> like 1009 entitled "Requirements for Consumer Internet > >>> Gateways" and "Requirements for Enterprise Internet > >>> Gateways". > >> Are you aware of RFC 4084 "Terminology for Describing Internet > >> Connectivity"? > >> > >> It is a rather different take on the same problem. > > > > But it really doesn't address the gateway hardware and software > > itself, but only what is provided to the customer boundary. If > > an IT/ networking person for a moderately small network can't > > walk into the local computer vendor and buy a boundary router > > and/or firewall that will support IPv4 and IPv6 without NATs or > > similarly-hostile addressing tricks or transformations, then > > nothing we do helps very much. And, having just taken another > > look at draft-ietf-v6ops-nap-06.txt, while it is clearly a step > > (or several) in the right direction, I don't see it moving me > > much closer to that walk into the local computer store, much > > less the ability to take it with the circa USD 50 - USD 100 in > > my hands that will buy a competent IPv4 Router-NAT-Firewall > > today. > > > > It also ignores one issue that 4084 does address: many of the > > ISPs supplying services who serve what you describe as the > > "small private network" market have discovered a significant > > revenue opportunity in restricting most customers to two or > > fewer public addresses. Simply crossing that threshold into > > availability of even a small number of relatively stable public > > addresses is often the excuse for pricing differences that may > > approach an order of magnitude. Sometimes that difference is > > justified by claims about service quality that the customer > > cannot measure or unbundle, sometimes by lifting of > > prohibitions, and sometimes by address scarcity but the reality > > is that, having discovered this revenue opportunity, there is > > reason to believe that ISPs would be unlikely to let go of it > > even if there were no scarcity argument available. > > > > Incidentally, in my experience, those "small private" networks > > somewhat more than ten hosts if the real entry threshold for the > > "medium/large" ones is "sufficient resources to acquire > > addressing independence" (section 5.1 of v6ops-nap-06). If that > > is really the criterion, and "addressing independence" implies > > PI address space, the number of networks in the range between > > what is usually thought of as the "residential" or "SOHO" > > category and the PI threshold is > > quite large, growing, and includes many medium-sized enterprises > > and networks. > > > > Please remember that, unlike some of the other contributors to > > this set of threads, I strongly dislike NATs, believe we should > > be migrating to IPv6 much more quickly than we have been, and > > that continued fussing by the IETF about IPv6 details and > > options has become part of the deployment problem. But I also > > think that we are most likely to make progress on these problems > > by being as clear-headed and objective about them as possible. > > That includes understanding that having the IPv4 network > > environment persist into this century --no matter how horrible > > the kludges are that are required to support it-- is building it > > own inertia against wide or rapid IPv6 deployment as people > > discover economic advantages and build operational practices > > around those kludges. Those advantages and practices may be > > harder to overcome than the technology barriers (real or > > imagined) themselves. > > > > john > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
