It seems good to keep the last sentence, as we don't want to risk breaking existing implementations. The same basic logic applies to why existing implementations are allowed to continue using site-local unicast addresses even though they were formally deprecated in RFC 3879.
Best regards, Tim Enos 1Sam16:7 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Antonio Querubin Sent: Tuesday, March 22, 2005 7:01 PM To: Bob Hinden Cc: ipv6@ietf.org Subject: Re: Proposed "IPv4-compatible IPv6" Deprecation text On Tue, 22 Mar 2005, Bob Hinden wrote: > Here is what I hope is the final text that specifies the deprecation of the > "IPv4-compatible IPv6 address". Included below are the revised sections > "IPv6 Addresses with Embedded IPv4 Addresses" and "IANA Consideration". > > Please review. I hope to submit an update draft tomorrow. > 2.5.5.1 IPv4-Compatible IPv6 Address > The "IPv4-compatible IPv6 address" is now deprecated because the > current IPv6 transition mechanisms no longer use them. New or > updated implementations are not required to support this address > type. Existing implementations and deployments may continue to use > these addresses. Can we just drop that last sentence altogether as it seems somewhat contrary to the rest of the paragraph? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
