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

["George, Wesley" <[e-mail]>]

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

Thanks,

Wes

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

> 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.

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.

>    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.

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.

>    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?

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

>       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?
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...

>       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"

WEG> Ack, will re-word.

>       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.

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.