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

[Fred Baker <[e-mail]>]

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