The IESG has no problem with the publication of 'IPv6 Rapid Deployment on IPv4 infrastructures (6rd)' <draft-despres-6rd-03.txt> as an Informational RFC. The IESG would also like the IRSG or RFC-Editor to review the comments in the datatracker (https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17368&rfc_flag=0) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. The IESG contact person is Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-despres-6rd-03.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary Technical Summary IPv6 rapid deployment (6rd) builds upon mechanisms of 6to4 (RFC3056) to enable a service provider to rapidly deploy IPv6 unicast service to IPv4 sites to which it provides customer premise equipment. Like 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure. Unlike 6to4, a 6rd service provider uses an IPv6 prefix of its own in place of the fixed 6to4 prefix. Working Group Summary This is an independent submission via the RFC Editor. Document Quality A French service provider has used this mechanism for its own IPv6 "rapid deployment": five weeks from first exposure to 6rd principles to more than 1,500,000 residential sites being provided quasi-native IPv6, under the only condition that they activate it. A large fraction of Google's IPv6 end users come from this ISP. The document has a number of issues that would have to be addressed if this were a standards track RFC. In particular, concerns have been raised about the implied large ISP allocation size. However, given that this is a documentation of a deployed mechanism it makes more sense to document the mechanism and its chosen tradeoffs; possible better designs should be addressed in future IETF work in the space. Personnel The responsible Area Director is Jari Arkko. RFC Editor Note The IESG finds response #2 from Section 3 of RFC 3932 appropriate, i.e. the IESG thinks that this work is related to IETF work done in a number of WGs, including V6OPS, SOFTWIRE, and BEHAVE, but this does not prevent publishing. In particular, we find that the relatively large deployment this mechanism has justifies documentation as an RFC. IESG Note Note #2 from Section 4 of RFC 3932 should be used. Or, if the new headers&boilerplates and rfc3932bis process is approved at the time of the publication of this RFC, no IESG note will be necessary. _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
