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
<brc@xxxxxxxxxxxxxx> wrote:
Michael,
On 2007-03-02 16:19, michael.dillon@xxxxxx 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf