Re: [v6ops] Last Call: <draft-ietf-v6ops-6to4-to-historic-04.txt> (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4 to Historic status) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



After a fair amount of thought, I have decided that I support
this document without reservation.

I support the recommendation that RFC 3056/3068 support should be off
by default in CPEs; the reasons for this are clear enough in my companion
draft. Specifically, I support the choice of "SHOULD NOT enable" (rather
than MUST NOT) because it leaves open the option for a CPE or host vendor to
enable RFC 3056/3068 by default if there is a sound reason to do so for a
specific product.

I support the recommendation to reclassify RFC 3056 as Historic,
because its time is past. The reason for inventing 6to4 in the
first place was for the benefit of customers whose ISPs could
not deploy IPv6. There is now no reason or excuse for a consumer
ISP to fail to deploy IPv6 for customers, so it is entirely
reasonable to consider the technique as Historic. This has no
impact on current successful use of 6to4 - the recommendation is
to retain existing relays "until traffic diminishes" and to follow
appropriate operational recommendations meanwhile. As my companion
draft indicates, relays advertising the 2002::/16 prefix are needed
as long as there is residual 6to4 traffic in the network.

Regards
   Brian Carpenter (co-author of RFC 3056)
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]