[Note]: 'Alain Durand (adurand@juniper.net) and Dave Ward (dward@juniper.net) are the document shepherds.

Note that Alain Durand''s e-mail address was updated on 5/25/2010.' added by Ralph Droms

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot comment]
1. Broadband Forum's TR-69 Residential Gateway management interface should be an Informational Reference

2. The corect terminology for MIB modules is 'SMIv2 MIB module' and not 'SNMP MIB'. There is however one more aspect here - I do not think that configuration by SNMP can be seen as an automatic provisioning method - it should rather belong to (manual) configuration by operator, as CE is the server (agent) to be configured by SNMP commands.

[Ballot discuss]
I support the comments made by David Harrington, and I have to add one more issue which strikes me as an omission that needs to be clarified before I can approve this document. In Section 7.1:

The four 6rd elements are set to values which are the same across all
  CEs within a 6rd domain.  The values may be configured in a variety
  of manners, including automatic provisioning methods such as the
  Broadband Forum's "TR-69" Residential Gateway management interface,
  an XML-based object retrieved after IPv4 connectivity is established,
  a DNS record, an SNMP MIB, PPP IPCP, or manual configuration by an
  end-user or operator.  This document describes how to configure the
  necessary parameters via a single DHCP option.  In order to guarantee
  interoperability, a CE SHOULD implement this DHCP option.  For
  consistency and convenience, this option format may be used by other
  automatic configuration methods by normative reference to this
  document.

I do not see how interoperability of configuration can be guranteed without the implementation by a CE being a MUST.

[Ballot comment]
1. Broadband Forum's TR-69 Residential Gateway management interface should be an Informational Reference

2. The corect terminology for MIB modules is 'SMIv2 MIB module' and not 'SNMP MIB'. There is however one more aspect here - I do not think that configuration by SNMP can be seen as an automatic provisioning method - it should rather belong to (manual) configuration by operator, as CE is the server (agent) to be configured by SNMP commands.

[Ballot discuss]
I support the comments made by David Harrington, and I have to add one more issue which trikes me as an omission that needs to be clarified before I can approve this document. In Section 7.1:

The four 6rd elements are set to values which are the same across all
  CEs within a 6rd domain.  The values may be configured in a variety
  of manners, including automatic provisioning methods such as the
  Broadband Forum's "TR-69" Residential Gateway management interface,
  an XML-based object retrieved after IPv4 connectivity is established,
  a DNS record, an SNMP MIB, PPP IPCP, or manual configuration by an
  end-user or operator.  This document describes how to configure the
  necessary parameters via a single DHCP option.  In order to guarantee
  interoperability, a CE SHOULD implement this DHCP option.  For
  consistency and convenience, this option format may be used by other
  automatic configuration methods by normative reference to this
  document.

I do not see how interoperability of configuration can be guranteed without the implementation by a CE being a MUST.

IANA comments:

QUESTION:

- what, if anything, do you want to put in the Data Length and Meaning
portions of the DHCP Option Registry?

Upon approval of this document, IANA will make the following assignment
in the "BOOTP Vendor Extensions and DHCP Options" registry at
http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml

Tag Name Data Length Meaning Reference
--- ---- ----------- ------- ---------
[TBD] OPTION_6RD [RFC-softwire-ipv6-6rd-09]

We understand the above to be the only IANA Action for this document.

[Ballot comment]
I recommend expanding 6rd in the title

section 1:
reference at first use of NBMA
s/aside of/simultaneously with/
"can be made with 6rd" - I think changing to a different wording woudl be clearer than "made with"

section 8, bullet 2. I found the sentence ill-formed. I think "will process" should have an object; I recommend rewording to improve the English.

section 9.1: s/absent of/absent/

section 9.2 s/allow packets/allow forwarding of packets/

section 11. the second paragraph gives a number of examples; are they all needed? Could this be made more concise?
Does the last paragraph of 11 belong more logically in section 10?

section 12. "sink route" - reference on first use?

[Ballot discuss]
I thought this was a well-written document. I have a few COMMENTS where I think the text could be clearer, and a few questions on RFC2119 usage.

1) some RFC2119 keywords are not capitalized; I think it would be clearer if they were.

2) I think it is important to understand the deployemnt and operational considerations, so saying in section 1 that such consdierations is out of scope strikes me the wrong way. And the document does discuss operational considerations in a number of places, so I recommend removing the last paragraph of section 1.

3) 7.1.1 6rdPrefix - "SHOULD be set to zero" - why not MUST? When is it acceptable to not set them to zero?

4) 7.1.1 reference for first use of RIB

5) section 8 s/not recommended/NOT RECOMMENDED/

6) in 9.1, s/may/might/ or s/may/could/

7) 9.2 "SHOULD drop packets" - why not MUST? when is it acceptable to not drop the packets?

8) 10. s/may migrate/can migrate/
s/In the event native IPv6 connectivity is also available, the CE MAY disable 6rd./When native IPv6 connectivity is available, an administrator can choose to disable 6rd./

9) 10. "Further considerations ... are not covered in this protocol specification." - where are they discussed?

10) the third paragraph of section 11 discusses leaving out redundant bits. Should this be written using MAY, and should this be discussed elesewhere, such as where the bit patterns are shown in 7?

11) section 12 discusses one possible mitigation. Shouldn't a standard mechanism for mitigation be defined so behaviors can be predicted? The description uses "may"; is MAY called for, or "might"?

12) I am unclear what "embeds" means in the two bullets in section 12, and the construction of "if ... but ..." seems ambiguous. I think this should be reworded.

[Ballot comment]
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.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Alain Durand and Dave Ward are the Shepherds. Both shepherds have
reviewed the document and believe it ready for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

We saw evidence of extensive review on the mailing list. The document
has been presented in softwires, v6ops, and dhc working groups.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No concerns.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

This is strictly a protocol specification. We believe that an
operational document discussing some of the various tradeoffs and
choices when deploying 6rd, particularly in the presence of native IPv6
as well, is necessary. Such a document will be part of the Softwires
WG deliverables.

We know of no IPR disclosures related to this document.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

Some individuals have expressed concern that the document doesn't go
into enough depth on certain subjects like MTU discovery/adaptation,
but in the chair's opinion most of those subject are general issues,
not specific to 6rd. Aside of this,
the document has strong support in the WG.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See theInternet-Drafts
Checklist <http://www.ietf.org/id-info/checklist.html>
andhttp://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

no need for doctor reviews.
Few very minor nits (the most important one in a reference to move
from normative to informative).
The authors have agreed to fix those during the final review process.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

See above, the reference to RFC 3964 should be moved from the
normative section to
the informative section.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

There is a request for one dhcp option code point in the IANA
considerations section.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

There is no formal language in the document.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:
Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

This document specifies an automatic tunneling mechanism tailored to
advance deployment of IPv6 to end users via a Service Provider's IPv4
network infrastructure. Key aspects include automatic IPv6 prefix
delegation to sites, stateless operation, simple provisioning, and
service which is equivalent to native IPv6 at the sites which are served
by the mechanism.

Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

This document was discussed in depth and well-reviewed. There is some
disagreement over small details, but overall WG consensus is strong to
publish this document.

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

There are multiple, independent, interoperable implementations of this
protocol today. One service provider has a large deployment of this
protocol, several other service providers have announced plans to deploy
or interest in deploying.