Subject: [Int-area] WGLC for http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00

From: Julien Laganier <[email-masked]>
Date: Thu, 23 Jun 2011 15:39:17 -0700

Folks,

We are hereby issuing a 2 weeks WGLC of the document "IPv6 Support
Required for all IP-capable nodes" available at
http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00

Abstract

   Given the global lack of available IPv4 space, and limitations in
   IPv4 extension and transition technologies, 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.  This document updates RFC1812, RFC1122 and
   RFC4084 to reflect the change in requirements.

This is a short, two and a quarter pages long, draft that received
significant support from participants to this WG. Please review the
draft and raise WGLC comments you might have before we can request
publication. This WGLC will conclude on 2010-07-07 5:00 PM PDT.

Thank you for your support,

--julien & scott

---

From: Fred Baker <[email-masked]>
Date: Thu, 23 Jun 2011 17:52:22 -0700

> 2.  Requirements and Recommendation
> 
> 
>    This draft updates the following documents:
> 
>    Updates [RFC1812] to note that IP nodes SHOULD no longer support IPv4
>    only.  This is to ensure that those using it as a guideline for IP
>    implementations use the other informative references in this document
>    as a guideline for proper IPv6 implementations.

When what became RFC 1812 was written, it was called "requirements for IP Routers". We changed that to "IPv4 Routers" in the context of the fact that we were working on several variations on IPng. I worry about trying to backdate IPv6 issues into the document; it is itself dated, and while the observations made there are good things to consider in an IPv6 network, probably are due careful consideration before invoking from a "requirements" perspective. 

I agree that routers SHOULD no longer be limited to IPv4. When RFC 1812 was written, they weren't limited to IPv4 either - they routinely ran DECnet, OSI, AppleTalk, and IPX to name a few.

Personally, I would prefer that this document not confuse itself by trying to update RFC 1812, but simply assert that IP nodes SHOULD support IPv6 and MAY support IPv4. For the present, anyone with a business plan will understand that "MAY" applies at some point in the future.

>    Updates [RFC1122] to redefine generic "IP" support to include and
>    require IPv6 for IP-capable nodes and routers.

Same concern with RFC 1122. For example, for IPv6 support, section 2 needs updating to mention, beside ARP, Neighbor Discovery. And do we agree that in an IPv6 network

      The packet send interface between the IP and link layers MUST
      include the 5-bit TOS field (see Section 3.2.1.6).
?

How about the various references in section 3.1?

Personally, I would prefer that this document not confuse itself by trying to update RFC 1122, but simply assert that IP nodes SHOULD support IPv6 and MAY support IPv4. For the present, anyone with a business plan will understand that "MAY" applies at some point in the future.

>    Updates [RFC4084] to move "Version Support" from Section 4,
>    "Additional Terminology" to Section 2, "General Terminology."  This
>    is to reflect the idea that version support is now critical to
>    defining the types of IP service, especially with respect to Full
>    Internet Connectivity.
> 
>    From a practical perspective, the requirements proposed by this draft
>    mean that:
> 
>       New IP implementations MUST support IPv6.

Paragraph 2 of section 2 says "SHOULD". Pick one?

>       Current IP implementations SHOULD support IPv6.

If they don't and are current, this is demanding a change; any change to said implementations is a new implementation. Hmmm?

>       IPv6 support MUST be equivalent or better in quality and
>       functionality when compared to IPv4 support in an IP
>       implementation.
> 
>       Helpful informative references can be found in [RFC4294], soon to
>       be updated by [I-D.ietf-6man-node-req-bis] and in [RFC6204]

This section says that it is "requirements". Rather than discussing "Helpful informative references", I'd suggest calling them "Node Requirements"

>       Current and new IP Networking implementations SHOULD support IPv4
>       and IPv6 coexistence (dual-stack), but MUST NOT require IPv4 for
>       proper and complete function.
> 
>       It is expected that many existing devices and implementations will
>       not be able to support IPv6 for one or more valid technical
>       reasons, but for maximum flexibility and compatibility, a best
>       effort SHOULD be made to update existing hardware and software to
>       enable IPv6 support.

I'm afraid that in many cases that is a vendor marketing decision. Yes, I'd like to see every non-IPv6 implementation upgraded. To the extent that they have hardware limitations (forwarding ASICs, filtering ASICs, memory, SAVI, ...), I wouldn't be amazed to find vendors saying they would rather obsolete older equipment than upgrade those issues. I think the IETF would do well to stay out of that morass.

---

From: "George, Wesley" <[email-masked]>
Date: Fri, 24 Jun 2011 15:05:35 -0400

Fred, thanks for the review, some comments below inline, marked with WEG>

Thanks,

Wes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred Baker
Sent: Thursday, June 23, 2011 8:52 PM
To: Julien Laganier
Cc: [email-masked]
Subject: Re: [Int-area] WGLC for http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00

WEG> I don't believe that the document is confused. The idea in linking to RFC1812 as an updated document is to ensure that those looking up RFCs related to basic requirements for IP routers find that this document exists and through it discover that there are now companion requirements defined for IPv6 routers that this document cites as informative references.

      The packet send interface between the IP and link layers MUST
      include the 5-bit TOS field (see Section 3.2.1.6).?

WEG> This document is not meant to replace existing standards defining IPv6, but to reference them. There is no need to reinvent the wheel by rewriting 1122 to include full IPv6 support when companion documents that cover that information already exists. Again, this is meant to be a trail of bread crumbs to point to the appropriate resources for those looking for guidelines on how to build an IP device.
That said, for both of the above concerns, if the consensus is that those references should be removed in order for the draft to get past WGLC, we'll do that. I'd like to hear from additional folks in the WG about this.

WEG> The first occurrence is not making the distinction between new vs current, and staying more generic, hence the SHOULD.

If they don't and are current, this is demanding a change; any change to said implementations is a new implementation. Hmmm?
WEG> I think that this is stretching a bit, and I'm not sure what you're recommending here. By the strictest definition, yes, the IPv6 implementation will likely be new. However, the entire implementation is not new. I don't know of any implementer who will rewrite otherwise functional code that isn't critical to making the new feature work. You don't say that you have a brand new house because you added a room and a patio to an existing structure...

WEG> Ack, will re-word.

WEG> We already know that the vendors' general view is "backporting IPv6 is hard, let's go shopping..." This was specifically worded to concede that it's not practical to simply demand that everything be updated and that there are legitimate limitations to where IPv6 can and cannot be supported, but still recommend that it be done where that's not the case. Therefore the authors believe that it keeps IETF out of that morass pretty effectively. Please be clearer as to what specifically you feel the above text is not covering and I'll be happy to try to incorporate those changes.

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: Fred Baker <[email-masked]>
Date: Fri, 24 Jun 2011 12:20:29 -0700

> WEG> I think that this is stretching a bit, and I'm not sure what you're recommending here. By the strictest definition, yes, the IPv6 implementation will likely be new. However, the entire impleme…

Well, no, but you might well say that you have a new room etc. In something that is IPv4-only and adds IPv6, it isn't sufficient to "add IPv6"; the psuedoheader changes sneak up stack, and the application API has to change to accommodate IPv6 in some way. This is actually fairly analogous to adding a room; the wall that used to be there is no longer there or is changed, and as a result various other parts of the house need work as well. I will argue that the IPv6 component of this changed system is new.

My biggest point in the email is to tease what you intend ("listen guys, I want IPv6 support; get off the dime") apart from the mechanisms you choose. Your fundamental point is, I think, a good one. The problem with updating RFCs 1122 and 1812 is that (having some experience with both) you can't hand-wave updates to them. You are in essence asking the reader to reinterpret remarks made about IPv4 in an IPv6 context, and they don't necessarily have obvious interpretations.

So I personally would prefer that the message be simplified.

"listen guys, I want IPv6 support; get off the dime"

---

From: Tina Tsou <[email-masked]>
Date: Fri, 24 Jun 2011 13:20:02 -0700

Hi,
This is a significant I-D, which will lead IPv6-related work become the
*only* work in IP standardization, not IPv4-specific work anymore,
eventually.

We keep our promises with one another - no matter what!

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Fred Baker
Sent: Friday, June 24, 2011 12:20 PM
To: George, Wesley
Cc: Julien Laganier; [email-masked]
Subject: Re: [Int-area] WGLC for
http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00

On Jun 24, 2011, at 12:05 PM, George, Wesley wrote:

> If they don't and are current, this is demanding a change; any change to
said implementations is a new implementation. Hmmm?

> WEG> I think that this is stretching a bit, and I'm not sure what you're
recommending here. By the strictest definition, yes, the IPv6 implementation
will likely be new. However, the entire implementation is not new. I don't
know of any implementer who will rewrite otherwise functional code that
isn't critical to making the new feature work. You don't say that you have a
brand new house because you added a room and a patio to an existing
structure...

Well, no, but you might well say that you have a new room etc. In something
that is IPv4-only and adds IPv6, it isn't sufficient to "add IPv6"; the
psuedoheader changes sneak up stack, and the application API has to change
to accommodate IPv6 in some way. This is actually fairly analogous to adding
a room; the wall that used to be there is no longer there or is changed, and
as a result various other parts of the house need work as well. I will argue
that the IPv6 component of this changed system is new.

My biggest point in the email is to tease what you intend ("listen guys, I
want IPv6 support; get off the dime") apart from the mechanisms you choose.
Your fundamental point is, I think, a good one. The problem with updating
RFCs 1122 and 1812 is that (having some experience with both) you can't
hand-wave updates to them. You are in essence asking the reader to
reinterpret remarks made about IPv4 in an IPv6 context, and they don't
necessarily have obvious interpretations.

"listen guys, I want IPv6 support; get off the dime"
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: "George, Wesley" <[email-masked]>
Date: Mon, 27 Jun 2011 11:37:02 -0400

-----Original Message-----
From: Fred Baker [mailto:[email-masked]]
Sent: Friday, June 24, 2011 3:20 PM
To: George, Wesley
Cc: Julien Laganier; [email-masked]
Subject: Re: [Int-area] WGLC for http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00

WEG> and if there's consensus that removing the updated RFCs list is the best way to proceed, than that is what we shall do. The authors (and I assume those who recommended other RFCs to list as being updated by this draft) were under the impression that there was precedent for updating a draft in this way, essentially saying "this is no longer complete, you need to look at these other standards too." My preference would have been for IPv6 RFCs (such as 1183/2460, etc) to update the equivalent IPv4 RFCs, but that predates my involvement in IETF. Looking at it now, I think it'd be more confusing to issue -bis versions of those documents to make that the case, and so the easiest path to that was to update the correct docs with a bridge draft of sorts that then includes forward references to the correct RFCs or to other drafts/RFCs that include the much more complete set of references (such as the node-req-bis and 6204).

I'm also open to recommendations for more substantive changes in the "updates RFC xxxx" language in this document to clarify and remove the potential confusion or reduce the level of handwaving in the current language to address your point about the less than obvious interpretation of the recommended updates. While I don't want this to end up addressing updates in a section-by-section manner in the referenced RFCs, I think a couple of sentences clarifying how this "update" should be interpreted would be appropriate.

Wes George

---

From: Benson Schliesser <[email-masked]>
Date: Mon, 27 Jun 2011 16:08:35 -0500

> http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00

Overall I support the spirit of this draft.  There is no doubt in my mind
that IPv6 is needed, is trending up in deployment, and must therefore be a
basic capability of a modern router.

I do share some of Fred's concern about "updating" old documents.
Specifically, I'm wary both of legitimate confusion interpreting other IETF
documents and of semantic games that might result.

I'm also skeptical of any IETF document that attempts to set "policy" rather
than define a standard.  This draft seems to be somewhat vague in a number
of ways, appearing more as a policy statement rather than concrete
definition of requirements.

Thus it is my hope that this draft evolves or leads to a future document,
such as a consolidated dual-stack router requirements document, which
specifies detailed requirements (with references) that can be objectively
evaluated as a standard.

Cheers,
-Benson

---

From: Joshua Shire <[email-masked]>
Date: Mon, 27 Jun 2011 15:58:22 -0600

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

>From a business prospective, it would be very beneficial to be able to
pick up a piece of kit and know that all of its features are fully
implemented in both 6 and 4 (as opposed to seeing something listed on a
spec sheet, buying because of it, trying to get it working, then calling
in to tech support only to have them tell you that this feature hasn't
been implemented in ipv6 yet and isn't planned until Q3 next year).

Thanks,
Joshua

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Benson Schliesser
Sent: Monday, June 27, 2011 3:09 PM
To: Julien Laganier; [email-masked]
Cc: [email-masked]
Subject: Re: [Int-area] WGLC for
http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00

> http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00

Overall I support the spirit of this draft.  There is no doubt in my
mind
that IPv6 is needed, is trending up in deployment, and must therefore be
a
basic capability of a modern router.

I do share some of Fred's concern about "updating" old documents.
Specifically, I'm wary both of legitimate confusion interpreting other
IETF
documents and of semantic games that might result.

I'm also skeptical of any IETF document that attempts to set "policy"
rather
than define a standard.  This draft seems to be somewhat vague in a
number
of ways, appearing more as a policy statement rather than concrete
definition of requirements.

Thus it is my hope that this draft evolves or leads to a future
document,
such as a consolidated dual-stack router requirements document, which
specifies detailed requirements (with references) that can be
objectively
evaluated as a standard.

Cheers,
-Benson

---

From: "George, Wesley" <[email-masked]>
Date: Tue, 28 Jun 2011 13:09:36 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Benson Schliesser
Sent: Monday, June 27, 2011 5:09 PM
To: Julien Laganier; [email-masked]
Cc: [email-masked]
Subject: Re: [Int-area] WGLC for http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00

WEG> Thanks

WEG> I think that the old document updates are important, but I'd like to try to address this concern if I can. I'd be happy to discuss changes to the existing text that better clarifies it in order to eliminate confusion and semantic games.

WEG> Well, the only policy an IETF document can really set is IETF policy. The policy statement (what IETF should do/change/not do within their protocol work) has been removed from this version per feedback we received in Prague that such things are not appropriate within a standards-track document. I and my fellow authors view what remains in this document as technical guidance for implementers. Technical guidance need not always be in the form of a protocol definition. In much the same way as IETF says "considered harmful" or "not recommended" or any of the other things we say before we truly declare something historic when a given implementation has been superseded by something else, we are providing technical guidance that IPv4-only devices are not generally a good technical solution due to the exhaustion of IPv4.
Regarding vagueness, again, I'm open to text suggestions to address, but we did purposely keep this a bit less specific because there is no way to know every possible use case, every possible exception, and everyone realizes that all IETF standards are open to interpretation during implementation no matter how ironclad the requirements are. Also, since the IETF is not a certification organization, the onus is on each person writing the checks to do their own testing to verify that what they're buying does what they want it to do.

WEG> If enough people believe that to be necessary, it'll get written. However it likely won't be by me. The technical standards for both IPv4 and IPv6 are already well-defined separately. The appropriate detailed IPv6 requirements and standards (unless you have additional recommendations that you believe to be missing) are identified by this document via the documents that it references and in turn, their references, especially omnibus documents like node-req-bis and 6204, which have multiple pages of normative and informative references related to IPv6 implementation details. I simply don't see the need to repackage those technical standards in a slightly different format to make the suggested dual-stack router requirements document.

That said, your private comment to the authors leads me to interpret your comments slightly differently, that this document should map IPv4 features and functions to IPv6 features and functions in order to more clearly define "equivalent or better in quality and functionality" between the two protocols. There was considerable debate about this, where we started getting into whether we should say anything about NAT66, whether a direct 1:1 mapping between IPv4 functions and IPv6 functions is really necessary, etc. The language used was a result of that discussion. At least by my interpretation, the WG specifically did not want to get into that level of detail in this document.
I suppose that it might make sense to expect that drafts which define a given IPv6 feature should identify the IPv4 feature that it is analogous to/replaces/eliminates the need for, and I would be willing to incorporate that recommendation into a BCP document that speaks to IETF policy in this area if people believe that would be helpful.

Thanks again for the feedback,

Wes George