[v6ops] 6rd and draft-ietf-v6ops-6to4-to-historic

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

On 2011-04-28 07:27, Ole Troan wrote:
> Ray,
> 
>> I obviously defer to you as the co-author of RFC5969.
>>
>> Would it be possible to include some text in your proposal to clarify and encapsulate this view?
>>
>>  e.g.
>>
>> "Historic Links between 6rd and 6to4
>>
>> Although 6rd has significant historic links with 6to4 (especially because 6to4 invented the underlying method of creating an IPv6 prefix based on an IPv4 address), 6rd was defined and improved in such ways that it does not share the same shortcomings for which the 6to4 transition mechanism is being moved to historic status. Furthermore, the definition of 6rd in RFC5969 is sufficiently decoupled from RFC3056 and RFC3068 that 6rd may be considered as a stand alone protocol in and of itself, independent of 6to4."
> 
> revision 01 now has the following:
> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-01
> 
>    6rd [RFC5969] utilizes the same encapsulation and base mechanism as
>    6to4, and could be viewed as a superset of 6to4 (6to4 could be
>    achieved by setting the 6rd prefix to 2002::/16).  However, the
>    deployment model is such that 6rd can avoid the problems described
>    here.  In this sense, 6rd can be viewed as superseding 6to4 as
>    described in section 4.2.4 of [RFC2026]
> 
> is that better?

Works for me. Also, there is no formal problem with RFC 5969 citing RFC 3056
even if the latter is made Historic. (It would be a wordsmithing problem if
RFC 5969 was to be updated.)

BTW, Section 5 of draft-ietf-v6ops-6to4-advisory also mentions this
topic briefly.

   Brian


> 
> cheers,
> Ole
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>