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

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

Yes, we should tweak the title.

Your other points are noted, pending the WGLC.

Thanks
   Brian

On 13/11/2014 09:46, David Farmer wrote:
> 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/>.
>