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

[David Farmer <[e-mail]>]

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

-- 
================================================
David Farmer               Email: [e-mail]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: [phone]
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================