Subject: [AAA-DOCTORS] FW: Evaluation: draft-despres-6rd-02.txt to Informational RFC

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 5 Apr 2009 17:06:20 +0200

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-despres-6rd-02.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.

IANA Note

  (Insert IANA Note here or remove section)