Hi Brian,
At 16:49 20-08-2011, Brian E Carpenter wrote:
I think most of your comments will be dealt with by
wordsmithing, but...
See comments below.
It't quite clear to me, but we could spell it out: s/IP/IPv4/.
That's clearer.
Yes it does. It clarifies, for consumer organizations for
example, the IPv6 is not additional technology but is part of
any general IP service.
Section 2 of RFC 4084 lists the primary IP service terms:
(a) Web connectivity
(b) Client connectivity only, without a public address
(c) Client only, public address
(d) Firewalled Internet Connectivity
(e) Full Internet Connectivity
And with the proposed update:
(f) Version support.
Does the service include IPv4 support only, both IPv4 and IPv6
support, or IPv6 support only?
I don't think that it makes sense as it stands. If you want to
wordsmith this, you could go with:
(f) IPv4 Internet Connectivity.
This service provides the user IPv4 Internet connectivity, with
one or more static public IPv4 addresses. Dynamic IPv4 addresses
that are long-lived enough to make operating servers practical
without highly dynamic DNS entries are possible, provided that
they are not characterized as "dynamic" to third parties.
(g) IPv6 Internet Connectivity.
This service provides the user/consumer IPv6 Internet connectivity,
with at least a /60 IPv6 prefix. Dynamic IPv6 addressing that are
long-lived enough to make operating servers practical
without highly dynamic DNS entries are possible, provided that
they are not characterized as "dynamic" to third parties.
Note: The above sub-section would need some more work as a host can
do with one IPv6 address whereas a home user could get an IPv6
prefix. I used a /60 prefix. Some people may view a /56 as more
appropriate. The sub-section could be broken into two, one for users
and the other one for consumers.
(h) Full Internet Connectivity.
This service provides the user with both IPv4 Internet Connectivity
and IPv6 Internet Connectivity.
They are about the best practices that the IETF wishes were
being used in the wild.
Then it should be expected that there will be a wide disconnect
between what the document says and what is happening in the wild. In
essence, if there is no motivation to adhere to some semblance of
reality, the IETF's wishes will remain best wishes.
Of course - we have that problem every time we update any RFC.
It is quite orthogonal to the question whether we *should*
update the RFC.
Most RFCs are not written for a wider audience.
Yes. Because IPv4 has no address extensibility, it was
impossible to update it for larger addresses. That has been
known since 1981 or thereabouts.
And that is probably why it did not make sense to update the IPv4
specifications to point to IPv6 specifications. In my opinion, it
also does not make sense to do likewise with those old RFCs. The
Abstract Section mentions that:
"this document deprecates the concept that an IP-capable node MAY
support IPv4 _only_, and redefines an IP-capable node as one which
supports either IPv6 _only_ or IPv4/IPv6 dual-stack."
IPv6 node requirements are defined in RFC 4294. It's merely an
informative reference in draft-ietf-intarea-ipv6-required-01. The
discussion about IPV4 address pool exhaustion (Section 1) is a
distraction from a definition of an IP-capable node. If the
intention is to push for IPv6 support in all nodes so that an IP node
is ubiquitous with IPv4 and IPv6, it would be helpful to have a clear
and concise document about that. I do not view concise as saying
"MUST support IPv6" and be done with it. The document would state
which technical specifications an IP-capable mode must support.
Regards,
-sm
1. http://www.6ip.cu/documentos-cuba/R140-08.pdf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf