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

From: "George, Wesley" <[email-masked]>
Date: Mon, 22 Aug 2011 10:00:16 -0400

From: Keith Moore <[email-masked]>
To: [email-masked]
Subject: Re: Last Call: <draft-ietf-intarea-ipv6-required-01.txt> (IPv6 Support Required for all IP-capable nodes) to Proposed Standard

I support publication of some document like this one. Suggestions for clarification to this document:

1. (section 2 in general) I think it's vague for this document to claim that it "updates" earlier documents as if it's changing the text of those documents.
The reader is left with only a vague impression of what is still in place from those documents and what has changed.

I suggest that the language in this draft be changed to first state each new or revised requirement, and then state how this changes
recommendations/requirements stated in earlier documents.
__________
WEG] We received similar feedback in the intarea last call, the "Updates..." language in section two is an attempt to do this clarification and is far more specific than the 00 version. It was attempting to note that rather than updating the details of the technical specs, it was pointing out that IP as generic could mean IPv4 or IPv6, but these documents are clearly IPv4 documents. Think of it as equivalent to %s/IP/IPv4/g. Since it appears that this was not completely successful, I'd appreciate more specific feedback or text suggestions to make it better.

2. section 2, page 4 reads:

reason: to me "SHOULD NOT support IPv4 only" seems potentially confusing.
__________
WEG] agree, will fix in next rev.

3. section 2, page 5 reads:

New IP implementations MUST support IPv6.

Current IP implementations SHOULD support IPv6.

In general, it's meaningless to impose a requirement on current implementations of anything.
____________
WEG] This is why it's a SHOULD instead of a MUST. Also, generally this document is saying "the IETF recommends that you support IPv6" so it seems a gap to leave out current implementations. This is also why the last paragraph in section 2 is there - we realize that there are going to be limitations to this and are trying to be pragmatic.

 Also, it's not clear what is meant by "new implementations" -
does this mean completely new implementations, or revisions of existing implementations?
____________
WEG] I'm wondering if it actually matters in this context? They both need to support IPv6, which is why both requirements are there. Ultimately, this is going to be open to interpretation by implementers regardless of how it is worded. Since the IETF has no control over what they decide to do, if they choose to interpret their implementation as not new and therefore covered by the SHOULD instead of the MUST, IETF has no recourse if they disagree with that interpretation.
That said, I am certainly open to additional text to clarify what "new implementations" are vs "current implementations" if you believe that it'll be helpful.

Suggest that this be restated. e.g. "Host and router IP implementations MUST support IPv6; to support only IPv4 is insufficient."
____________
WEG] This may be a way to solve. We'll consider in the revision.

4. also section 2, page 5:

IPv6 support MUST be equivalent or better in quality and
functionality when compared to IPv4 support in an IP
implementation.

This statement could be taken too broadly, e.g. as applying to service offerings rather than just host and router implementations.
_____________
WEG] It was intended to be taken as broadly as possible. It's not necessarily limited to host and router implementations, though that is indeed its primary focus. How is it a bad thing if a service offering interprets this to mean that the IETF recommends that they support IPv6?

Suggest instead:
Support for the IPv6 protocol in hosts and routers MUST
be equivalent or better in quality and functionality when
compared to IPv4 support in the same products.

Even then, this strikes me as problematic. Should an implementation that cannot provide support for every IPv6 feature (perhaps because of inherent
differences between IPv4 and IPv6, or because some feature hasn't yet been updated to support IPv6) be expected to remove features from its IPv4 stack so that
its IPv6 stack is "equivalent or better"?
______________
WEG] For what it's worth, I'm aware of several businesses that are using language similar to this in their vendor requirements documents. Basically, making it incumbent on the implementer to ensure that their gear supports features in both IPv4 and IPv6 rather than calling out specific features and thus risking missing some. So, I think the answer to your question is that it's a business decision on the part of the implementer. Some of the very early comments we received on this draft indicated a concern that people would implement the bare minimum IPv6 support and call it a day, making it mostly useless by comparison because it was so limited in functionality. This more generic text was chosen to cover this concern without getting us ratholed into a discussion about whether (for example) NAT is required in IPv6 because it's supported in IPv4 today. The larger discussion about feature parity in IPv4 vs IPv6 is a good bit longer I think, but we'd be willing to discuss it briefly in this draft if you think it would be useful. Perhaps:
        In this context, IPv4-IPv6
      feature parity is the absence of gaps where functionality exists
      in IPv4 but has no equivalent in IPv6.  Note that this does not
      mean a direct 1:1 relationship where every feature that exists in
      IPv4 will exist in IPv6.  This is because IPv6 eliminates the need
      for some features that exist in IPv4, IPv4 supports some features
      that are no longer in use, and some existing IPv4 features are
      integrated into other parts of IPv6.  In addition, as new features
      and implementations take advantage of the differences between IPv6
      and IPv4, it is expected that IPv6 will surpass IPv4 and feature
      parity will begin to swing in the other direction as the decision
      is made not to implement certain features and protocols with
      specific support for IPv4.

At the very least, I think the MUST should be a SHOULD.
__________
WEG] would any of the above clarification change your mind? I think dropping this to a SHOULD leaves a much larger opening for incomplete IPv6 implementations.

Thanks for the comments,
Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "George, Wesley" <[email-masked]>
Date: Mon, 22 Aug 2011 15:44:58 -0400

From: SM <[email-masked]>
To: Brian E Carpenter <[email-masked]>
Reply-to: [email-masked]
Subject: Re: Last Call: <draft-ietf-intarea-ipv6-required-01.txt> (IPv6 Support Required for all IP-capable nodes) to Proposed Standard

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.

________
WEG] I think that you have a point that this update is a little weak in its current form. I don't have a problem with some clarifying text, but I think that the problem with the above is that you now get into situations where IPv4 internet connectivity by that definition is no longer possible due to a lack of available addresses. In other words, each of the defined items in the existing section 2 are applicable to IPv4 and IPv6 separately. So perhaps it needs to discuss the fact that there are now multiple permutations of the items in section 2, e.g. where the host has IPv6 internet connectivity, but really only has client/no public IPv4 connectivity.
Then we're into value-judgment-land regarding whether full IPv6 connectivity coupled with NAT for IPv4 is considered "full internet connectivity" or if only true dual-stack is acceptable for that definition, etc.

Brian was the one who originally suggested this RFC be added as updated by this draft, so I'm keen to hear his opinion as well.

(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.
_________
WEG] I think that this definition is going to be problematic. There are plenty of other documents which already define IPv6 connectivity, and we are unlikely to reach consensus on any definition that includes a prefix size, but I'd be interested in opinions on the rest of it assuming that the prefix size recommendation is dropped.

Thanks
Wes George