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

[David Farmer <[e-mail]>]

On my first pass I missed the current title "Deprecating Connection of 
IPv6 Domains via IPv4 Clouds (6to4)", this implies more than is intended 
by the current consensus.  So, I'd suggest the title be changed to 
reflect the new scope of the Draft, how about "Deprecating the Anycast 
Prefix for 6to4 Relay Routers".

More responses inline;

On 11/11/14, 14:29 , Brian E Carpenter wrote:
...
> On 12/11/2014 08:33, David Farmer wrote:
...
>> But, I feel the Draft should also either update or replace RFC6343.
>> Minimally, I think it is important for there to be a metadata linkage
>> between RFC6343 and the Draft.  I would suggest a formal update to
>> Section 4 of RFC6343 substituting the use of Router 6to4 in place of
>> Anycast 6to4.
>
> 6343 is non-normative, so I'm not sure that we need to formally
> update it.  Also I don't agree that we should *encourage* people
> to apply the Router 6to4 scenario (which has been essentially
> ignored by the market for 13 years). But you are correct that some
> of the guidelines in 6343 might be taken as a positive recommendation
> to run an anycast relay, so how about adding this:
>
> "The guidelines in Section 4 of [RFC6343] remain valid only for
> those who choose to continue operating Anycast 6to4 despite its
> deprecation."

OK, that is probably good enough, but I'd still like to see a metadata 
linkage from RFC 6343 to the Draft such that an update provides even 
though RFC 6343 is non-normative.

>> Regardless, Section 4.5 of RFC6343 recommends the use of 192.88.99.1 as
>> the IPv4 source address for Return Relay traffic, this no longer seem
>> appropriate with the deprecation of 192.88.99.1, the prefix
>> 192.88.99.0/24, and Anycast 6to4 in general.  The 6th paragraph of
>> Section 4 of the Draft discusses Return Relays and references Section
>> 4.5 of RFC6343, I believe the intent is that "content providers might
>> choose to continue operating such a relay", but I think the
>> recommendation regarding the use of 192.88.99.1 as the IPv4 source
>> address of such traffic, contained in Section 4.5 of RFC6343 could be
>> confusing and is no longer appropriate.
>
> Why? Setting 192.88.99.1 as a *source* address is orthogonal to whether
> it's filtered by the routing system as a destination. It's pretty much
> harmless.

I guess my issue was that the recommendation that routes for 192.88.99.1 
be filtered will be taken by some operators to also filter traffic to or 
from 192.88.99.1 as well. How about an explicit recommendation against 
filtering traffic to or from 192.88.99.1, then the source address issue 
is orthogonal.  But, if traffic sourced from 192.88.99.1 gets filtered, 
then the issue is not orthogonal.

Also, I'd like to see the recommendation expanded beyond just "Internet 
service providers", how about "All networks, but in particular Internet 
service providers".  I'd also like to see the recommendations regarding 
Return Relays to include similar wording, focusing on, but not limited 
to content providers.

So how about replacing;

    Internet service providers SHOULD filter out routes to 192.88.99.1.

With;

    All networks, but in particular Internet service providers, SHOULD
    filter routes for 192.88.99.1 or the prefix 192.88.99.0/24, yet they
    SHOULD NOT filter traffic sourced from or destine to 192.88.99.1.

>> The draft says RFC6890 should be updated to remove "the 6to4 relay
>> anycast prefix (192.88.99.0/24)", but RFC6890 doesn't need to be
>> updated.  RFC68980 created "Special-Purpose IP Address Registries", no
>> update to the RFC is necessary, IANA only needs to update the
>> appropriate registry, which is already requested in section 5.  You may
>> want to specifically call out the appropriate registry "IPv4
>> Special-Purpose Address Registry" in section 5, but there is no need to
>> update RFC6890.
>
> Table 10 of 6890 explicitly mentions 192.88.99.0/24, so I think it
> does need to be updated. Actually we could do it right here in the
> draft by adding "Updates: 6890" and specifying that Table 10 is
> deleted. We do need to improve the IANA Considerations wording
> on that point, too.

 From RFC 6890;
    2.2.2.  IPv4 Special-Purpose Address Registry Entries

    Tables 1 though 16, below, represent entries with which IANA has
    initially populated the IPv4 Special-Purpose Address Registry.

Table 10, along with tables 1 through 16, are only the initial data to 
go in the registry, the whole point of creating the registry is not to 
have publish summary RFCs or even update an RFC every time something 
changes.  With the execution of RFC 6890 and the creation of the 
registries, then the registries themselves become the authoritative 
references and sources for the information, the information in the 
tables of RFC 6890 are essentially Historical once the registries are 
created.  So, unless the intent was to modify the policy for the 
registry itself I don't see the need to update RFC 6890.

I'll leave it to you, the WG Chairs, and the AD to consult with IANA on 
the best solution, but below is what I was thinking for the IANA 
Considerations section.  There isn't a status field for an entry in the 
registry, so I thought setting the name to "deprecated" with the 
original name in parenthesis seemed a reasonable solution to communicate 
the intended result.  Would we want to add a Termination Date?  Maybe 
like December 2020?

    5.  IANA Considerations

        IANA is requested to update the "IPv4 Special-Purpose Address
        Registry" [IANA.IPv4] for the prefix 192.88.99.0/24 as defined in
        Table 1.  Redelegation of this prefix for any usage requires
        justification via an IETF Standards Action [RFC5226].


        +----------------------+-------------------------------------+
        | Attribute            | Value                               |
        +----------------------+-------------------------------------+
        | Address Block        | 192.88.99.0/24                      |
        | Name                 | Deprecated (6to4 Relay Anycast)     |
        | RFC                  | [draft-ietf-v6ops-6to4-to-historic] |
        | Allocation Date      | June 2001                           |
        | Termination Date     | N/A                                 |
        | Source               | True                                |
        | Destination          | True                                |
        | Forwardable          | True                                |
        | Global               | True                                |
        | Reserved-by-Protocol | False                               |
        +----------------------+-------------------------------------+

                Table 1: 6to4 Relay Anycast


    [IANA.IPv4]  IANA, "IPv4 Special-Purpose Address Registry",
 
<http://www.iana.org/assignments/iana-ipv4-special-registry/>.

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