IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
RFC 5569

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: RFC Editor <rfc-editor@rfc-editor.org>
Cc: The IESG <iesg@ietf.org>, <iana@iana.org>, ietf-announce@ietf.org
Subject: Re: Informational RFC to be: draft-despres-6rd-03.txt 

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.