Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt

[Brian E Carpenter <[e-mail]>]

Hi,

Since we are already post-WG Last Call, the authors will wait for
direction from the WG Chairs before making any further changes.

Regards
   Brian

On 10/01/2015 10:44, David Farmer wrote:
> On 1/4/15, 13:10 , Brian E Carpenter wrote:
>> This version is intended to respond to Keith Moore's comments before
>> the holidays, with a number of clarifications and simplifications.
>> There is not intended to be any change to the actual recommendations.
> 
> I think the new draft is an improvement, I did a detailed review and have a list of several items for you to consider;
> 
> 1. In section 3, the second sentence of the first paragraph and the first sentence of the second paragraph seem to say virtually
> the same thing.
> 
> I suggest leaving the first paragraph as-is, deleting the first sentence of the second paragraph, and slightly rewriting the
> remainder of the second paragraph, maybe as follows;
> 
>    In the forward direction a 6to4 node will send native IPv6 traffic
>    to a 6to4 relay router, that is connected both to the 6to4 cloud and
>    to native IPv6.  In the reverse direction a 2002::/16 route is
>    injected into the native IPv6 routing domain to attract traffic from
>    native IPv6 nodes to a 6to4 relay router.  It is expected that
>    traffic will use different relays in the forward and reverse
>    direction.
> 
> 2. The last paragraph of section 3 says;
> 
>    Peer-to-peer usage of the 6to4 mechanism, not depending on the
>    anycast mechanism, might exist in the Internet, largely unknown to
>    operators.  This is harmless to third parties and the current
>    document is not intended to prevent such traffic continuing.
> 
> This could be taken by some to imply that the document intends to prevent anycast 6to4 traffic from continuing, more than simply
> deprecating anycast 6to4, I'd suggest rewriting the paragraph, maybe as follows;
> 
>    Peer-to-peer usage of the 6to4 mechanism exists in the Internet,
>    likely unknown to many operators.  This usage is harmless to third
>    parties and is not dependent on the anycast 6to4 mechanism that this
>    document deprecates.
> 
> 3. In section 4, first paragraph, I believe anycast 6to4 needs to be default disabled in any new 6to4 implementation.  Maybe add
> the following to the paragraph;
> 
>    However, if included in any new implementations, the anycast 6to4
>    mechanism MUST NOT be enabled by default.
> 
> 4. Section 4, fourth paragraph, is confusing me. It says;
> 
>    Implementations capable of acting as 6to4 routers MUST NOT enable
>    6to4 without explicit user configuration.  In particular, enabling
>    IPv6 forwarding on a device MUST NOT automatically enable 6to4.
> 
> As written the first sentences seems to be repeating the last sentence of third paragraph, just above it.  I think maybe it was
> meant to say;
> 
>    Implementations capable of acting as IPv6 routers MUST NOT enable...
> 
> 5. In previous discussions of the text in section 4, sixth paragraph, the issue of uRPF came up.  I think something about uRPF,
> BCP38, and BCP84 should get added to this paragraph.  Maybe something like this;
> 
>    This includes ensuring that traffic from a local 6to4 return relay
>    with a source address of 192.88.99.1 is allowed through
>    Anti-spoofing filters such as those described in [BCP38] and [BCP84]
>    or through Unicast Reverse-Path-Forwarding (uRPF) checks.
> 
> 6. On the more general question of filtering and the intended affect of deprecation, I would like to see the issue more strongly
> addressed with something like the following added;
> 
>    This deprecation does not constitute a recommendation for the
>    generalized filtering of traffic or routes for 6to4 or even anycast
>    6to4.  Both the basic 6to4 and anycast 6to4 mechanisms remain valid
>    traffic to be carried on the Internet.  In general terms this
>    document simply recommends against further deployment of the anycast
>    6to4 mechanism, calls for current 6to4 deployments to evaluate the
>    efficacy of continued use of the anycast 6to4 mechanism, and makes
>    recommendations intended to prevent any use of 6to4 from hampering
>    broader deployment and use of native IPv6 on the Internet as a
>    whole.
> 
> 7. We should have recommendations applicable to operators of the hosts, something like the following;
> 
>    All hosts using 6to4 SHOULD support the IPv6 address selection
>    policy described in [RFC6724] or be manually configured with an
>    address selection policy preferring IPv4 over a 6to4 source
>    address.  Further, 6to4 hosts SHOULD support "Happy Eyeballs"
>    [RFC6555] or use a browser supporting "Happy Eyeballs".  Any hosts
>    not meeting these requirements SHOULD NOT use, or continue to use,
>    the deprecated anycast 6to4 mechanism.
> 
> 9. On a higher level, section 4 seem to be a bit of a hodgepodge of issues and ideas;  I'm thinking split out the
> recommendations into a separate section.  Maybe even split the recommendations into separate operational and implementation
> sections or sub-sections if you prefer.
> 
> Taking this into account, including the issues for section 4 from above and taking editorial license to rearrange and rewrite a
> few things, I suggest something like the following;
> 
> ---
> 
> 4.  Deprecation
> 
>    This document formally deprecates the anycast 6to4 transition
>    mechanism defined in [RFC3068] and the associated anycast IPv4
>    address 192.88.99.1. It is no longer considered to be a useful
>    service of last resort.
> 
>    The prefix 192.88.99.0/24 MUST NOT be reassigned for other use except
>    by a future IETF standards action.
> 
>    The guidelines in Section 4 of [RFC6343] remain valid for those who
>    choose to continue operating Anycast 6to4 despite its deprecation.
>    However, 6to4 Provider Managed Tunnels [RFC6732] will no longer be
>    necessary, so they are also deprecated by this document.
> 
>    The basic unicast 6to4 mechanism defined in [RFC3056] and the
>    associated 6to4 IPv6 prefix 2002::/16 are not deprecated.  The
>    default address selection rules specified in [RFC6724] are not
>    modified.
> 
>    This deprecation does not constitute a recommendation for the
>    generalized filtering of traffic or routes for 6to4 or even anycast
>    6to4.  Both the basic 6to4 and anycast 6to4 mechanisms remain valid
>    traffic to be carried on the Internet.  In general terms this
>    document simply recommends against further deployment of the anycast
>    6to4 mechanism, calls for current 6to4 deployments to evaluate the
>    efficacy of continued use of the anycast 6to4 mechanism, and makes
>    recommendations intended to prevent the use of 6to4 from hampering
>    broader deployment and use of native IPv6 on the Internet as a
>    whole.
> 
>    Incidental references to 6to4 should be reviewed and possibly removed
>    from other IETF documents if and when they are updated.  These
>    documents include RFC3162, RFC3178, RFC3790, RFC4191, RFC4213,
>    RFC4389, RFC4779, RFC4852, RFC4891, RFC4903, RFC5157, RFC5245,
>    RFC5375, RFC5971, RFC6071 and RFC6890.
> 
> 5. Implementation Recommendations
> 
>    Implementations MUST NOT enable the basic unicast 6to4 mechanism
>    defined in [RFC3056] without explicit user configuration.  Further,
>    it is NOT RECOMMENDED to include the anycast 6to4 mechanism defined
>    in [RFC3068] in any new implementations.  However, if included in
>    any new implementations, the anycast 6to4 mechanism MUST NOT be
>    enabled by default.
> 
>    All implementations that include 6to4 SHOULD also include "Happy
>    Eyeballs" [RFC6555] and the default address selection rules
>    specified in [RFC6724].
> 
>    Implementations capable of acting as IPv6 routers MUST NOT enable
>    6to4 without explicit user configuration.  In particular, enabling
>    IPv6 forwarding on any device MUST NOT automatically enable 6to4.
> 
> 6. Operational Recommendations
> 
>    All hosts using 6to4 SHOULD support the default address selection
>    rules specified in [RFC6724] or be manually configured with an
>    address selection rule preferring IPv4 over a 6to4 source
>    address.  Further, 6to4 hosts SHOULD support "Happy Eyeballs"
>    [RFC6555] or use a browser supporting "Happy Eyeballs".  Any hosts
>    not meeting these requirements SHOULD NOT use, or continue to use,
>    the deprecated anycast 6to4 mechanism.
> 
>    Current operators of an anycast 6to4 relay with the IPv4 address
>    192.88.99.1 SHOULD review the information in [RFC6343] and the
>    present document, and then consider carefully whether the anycast
>    relay can be discontinued as traffic diminishes.  Internet service
>    providers that do not operate an anycast relay but do provide their
>    customers with a route to 192.88.99.1 SHOULD verify that it does in
>    fact lead to an operational anycast relay, as discussed in
>    Section 4.2.1 of [RFC6343].  Furthermore, Internet service providers
>    and other network providers MUST NOT originate a route to
>    192.88.99.1, unless they actively operate and monitor an anycast 6to4
>    relay service as detailed in Section 4.2.1 of [RFC6343].
> 
>    Operators of a 6to4 return relay responding to the IPv6 prefix
>    2002::/16 SHOULD review the information in [RFC6343] and the present
>    document, and then consider carefully whether the return relay can be
>    discontinued as traffic diminishes.  To avoid confusion, note that
>    nothing in the design of 6to4 assumes or requires that return packets
>    are handled by the same relay as outbound packets.  As discussed in
>    Section 4.5 of RFC 6343, content providers might choose to continue
>    operating a return relay for the benefit of their own residual 6to4
>    clients.  Internet service providers SHOULD announce the IPv6 prefix
>    2002::/16 to their own customers if and only if it leads to a
>    correctly operating return relay as described in RFC 6343.  IPv6-only
>    service providers, including those operating a NAT64 service
>    [RFC6146], are advised that their own customers need a route to such
>    a relay in case a residual 6to4 user served by a different service
>    provider attempts to communicate with them.
> 
>    Networks SHOULD NOT filter out packets whose source address is
>    192.88.99.1, because this is normal 6to4 traffic from a 6to4 return
>    relay somewhere in the Internet.  This includes ensuring that traffic
>    from a local 6to4 return relay with a source address of 192.88.99.1
>    is allowed through Anti-spoofing filters such as those described in
>    [BCP38] and [BCP84] or through Unicast Reverse-Path-Forwarding
>    (uRPF) checks.
> 
> Thanks
>