Scenarios and Analysis for Introducing IPv6 into ISP Networks

Note: This ballot was opened for revision 03 and is now closed.

(David Kessens) Yes

(Harald Alvestrand) No Objection

Comment (2004-05-26 for -)
No email
send info
Reviewed by Mark Allman, Gen-ART

This document is mostly fine to publish as an informational RFC.

  + It could really use a pass to get rid of alot of "this", "these" and
    "its".  In some places it is very confusing what the author is
    actually referring to.

  + More references to various bits of the technology would be nice
    (e.g., to Teredo (among others); although maybe I just missed this

  + Some statements could be shored up a bit.  E.g., on page 10 it is
    noted that "RIPng is not appropriate in most contexts".  It'd be
    nice if there was a small bit of explanation or a reference here.

The document doesn't hurt.  I am not sure how much I thought it would
help -- everything seems pretty straightforward.  And, it is not clear
that this is really an "experience" piece.  That said, there is some
decent stuff in here, too.

(Steven Bellovin) (was Discuss) No Objection

Comment (2004-05-25)
No email
send info
The document doesn't discuss provisioning at all.  I'm willing to be told that that's out of scope, but billing and accounting are mentioned.  More generally, all of these are operations support systems, and most of these tend to have v4-specific assumptions built in.

The relative scarcity of v6-capable firewalls is an obstacle to many managed services.

(Margaret Cullen) No Objection

(Ted Hardie) (was Discuss) No Objection

(Scott Hollenbeck) No Objection

(Russ Housley) No Objection

Comment (2004-05-26 for -)
No email
send info
  In section 1.1: s/present document/document/

  Please expand "IX", "DS", and "ACLs" the first time they are used.

  I do not understand the dotted line between the Network and Service
  Operation box and the Customer Connection 1 box on Figure 1.  There
  is no discussion that provides insight.  There is also no discussion
  of the Peering postion of the figure.

  In section 4.1.1:
    s/1) and 2)/Approaches 1) and 2)/
    s/However, 1)/However, approach 1)/
    s/2) may not be possible/Approach 2) may not be possible/
    s/equivalent to 4)/equivalent to approach 4)/

  In section 4.3: s/IPv4 or IPv6 only/IPv4- or IPv6-only/

  In section 5.2: s/Radius traffic/RADIUS traffic/

  An informational reference for RADIUS is needed.

(Allison Mankin) No Objection

(Thomas Narten) (was Discuss, No Objection, Discuss) No Objection

Comment (2004-05-27)
No email
send info
>    Large end sites are usually running managed network.  

doesn't parse.

>    Even though the RIR policies on getting IPv6 prefixes require the 
>    assignment of at least 200 /48 prefixes to the customers, this type 
>    of transit provider obtains an allocation nonetheless, as the number 
>    of customers their customers serve is significant. The whole backbone 

This isn't entirely true, and has been changing. Best not to include
details of the RIR requirement, since its not critical to this

(Bert Wijnen) No Objection

Comment (2004-05-27 for -)
No email
send info
   [BCP38UPD]      F. Baker, P. Savola "Ingress Filtering for
                   Multihomed Networks"
                   Work in progress
Should be updated to point to RFC 3704 (BCP84)