Re: Last Call: <draft-ietf-intarea-ipv6-required-01.txt> (IPv6 Support Required for all IP-capable nodes) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]