IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification
RFC 5969

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

(Jari Arkko) Yes

(Ron Bonica) Yes

(Ralph Droms) Yes

(Adrian Farrel) Yes

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Lars Eggert) No Objection

(David Harrington) (was Discuss) No Objection

Comment (2010-05-19)
No email
send info
COMMENTS:
some RFC2119 keywords are not capitalized; I think it would be clearer if they were. (lots of "may" that might be better as "might")

idnits in verbose mode reported a number of problems, but that might be the result of my saved version from the datatracker. Please check using the verbose options for idnits.

(Russ Housley) No Objection

Comment (2010-05-19)
No email
send info
  Please consider the minor issues raised in the Gen-ART Review by
  Pete McCann on 17 May 2010.

  Section 7:
     The configured values for these four
     6rd elements are identical for all CEs and BRs within a given 6rd
     domain.
     ...
     6rdBRIPv4Address    The IPv4 address of the 6rd Border Relay for a
                         given 6rd domain.

  Taken together, these statements seem to imply that there can only be
  one BR for a given domain, or at least that all CEs must be configured
  to have the same set of BRs.  I note that in section 7.1.1 it is
  possible to provision more than one BR address.  Can this set be
  different for different CEs?  I can imagine a situation where
  different CEs are homed on different BRs.  

  Section 9.2:
     In order to prevent spoofing of IPv6 addresses, the 6rd BR and CE
     MUST validate the source address of the encapsulated IPv6 packet with
     the IPv4 source address it is encapsulated by according to the
     configured parameters of the 6rd domain.  

  This seems to say that the CE should match the source IPv4 address of
  the BR to the source address of the encapsulated IPv6 packet, when
  receiving traffic from a BR.  I assume that isn't what you meant.

Alexey Melnikov No Objection

Comment (2010-05-09 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
7.  6rd Configuration

   For a given 6rd domain, the BR and CE MUST be configured with the
   following four 6rd elements.  The configured values for these four
   6rd elements are identical for all CEs and BRs within a given 6rd
   domain.

   IPv4MaskLen         The number of high-order bits that are identical
                       across all CE IPv4 addresses within a given 6rd
                       domain.  For example, if there are no identical
                       bits, IPv4MaskLen is 0 and the entire CE IPv4
                       address is used to create the 6rd delegated
                       prefix.  If there are 8 identical bits (e.g., the
                       Private IPv4 address range 10.0.0.0/8 is being
                       used), IPv4MaskLen is equal to 8.

This might be obvious to other readers, but it wasn't obvious to me until
I saw the example at the end of Section 7.1.1: you should say that
the IPv4MaskLen high-order bits are stripped from the IPv4 address before
constructing the corresponding 6rd delegated prefix.


   6rdPrefix           The 6rd IPv6 prefix for the given 6rd domain.

   6rdPrefixLen        The length of the 6rd IPv6 prefix for the given
                       6rd domain.

Does this include the IPv4 part? I don't think it does, but you should clarify.

(Tim Polk) No Objection

Comment (2010-05-18 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I support issues 11) and 12) in Dave's discuss.

With regard to 11), is there any scenario where the BR IPv4 address needs to be reachable from
outside the SP's 6rd domain?

(Dan Romascanu) (was Discuss) No Objection

Comment (2010-05-20)
No email
send info
The following comment made by Joel Jaeggli in his OPS-DIR review should be addresed:

Once a mapping  between ip4 addresses and /64 or shorter prefixes is established within a service provider, it's not going away for a long time.

If used with frequency by ISPs (and customers of ISPS that use them as
lirs) this will soak up sufficient ipv6 address space to move the requirements for direct assignments and ISP/LIR operations around considerably.

This proposal if widely deployed therefore has impact on current prefix assignment policies for ipv6 in the RIRs.

(Peter Saint-Andre) No Objection

(Sean Turner) No Objection