Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions
draft-ietf-dime-4over6-provisioning-06

[Ballot comment]
As reported by Tim Chown in his OPS DIR review:
Overall, I believe the document is Ready. Despite its nature (as a list
of definitions) it generally reads very well.

There are some minor typos, and items to be checked, as listed below,
some of which would no doubt be picked up by the RFC Editor:

1. Section 2.1 line 4, should be “provisions” (plural).

2. Section 2.5, line 5 of second bullet point, “IPv4” not “Pv4”.

3. Section 3.3.2. I found the third paragraph a little clumsy to read;
  perhaps clarify the SSM prefix of ff3x::/32 in effect being a /96?.
  Also, do you mean bits 33-95 here, or bits 32-95 (twice)?

4. Section 3.5, Figure 5. Should the vertical lines be below 8 and 16,
  rather than below 7 and 15?

5. Section 6 reads a little strangely, in that it says in 6.1 “hey, you can
  mitm Diameter”, then 6.2 says “you MUST use TLS/IPsec avoiding
  intermediate nodes”. Seems a little conflicting in outlook?

6. Two transition drafts cited in the text are now published as RFC 7596
  and RFC 7597.

[Ballot comment]
Thanks for an easy-to-read document. I have a few questions and comments, that I hope can be resolve easily:

-- 3.2:
Is it possible (or reasonable) for the FQDN to include an internationalized domain name? That is, is there a need for a idn or precis dependency? (I'm not saying there _is_ such a need; I'm just asking.)

-- 6.1, 2nd paragraph:

So you mean MiTM attacks _on_ peers, or _by_ peers? I assume the second, since the first can be mitigated with TLS. (I’m not sure I would call this a MiTM per se, it’s just an issue that compromised or malicious nodes already in the path may do bad things.)

-- 6.2:
Thanks for including this--but I think it needs a bit more.  I assume from these sections that some of these AVPs are "security-sensitive" as defined in the referenced section of RFC 6733. That section invokes requirements to use mutually authenticated TLS or IPSec, and to be sure that messages do not traverse any nodes that are not explicitly trusted. It would be good to explicitly list which AVPs from this draft qualify as such (unless the answer is "all of them"), and to explicitly mention that the additional requirements apply to their use.

[Ballot comment]
Thanks for the extra mention of risks without end-to-end encryption int he security considerations section.  It is good to see this included as a consideration, would be even better if solved and deployed.  :-)

[Ballot comment]
A nit - this text

  [RFC6519] sets a precedent for representation of the IPv6 address of
  a border router as an FQDN.  This can be dereferenced to one or more
  IP addresses by the provisioning system before being passed to the
  customer equipment, or left as an FQDN as it as in [RFC6334].
                                          ^^^^^^^^^^^                   
seems garbled.

In this text

3.4.1.  Delegated-IPv6-Prefix As the IPv6 Binding Prefix

  The Delegated-IPv6-Prefix AVP (AVP code 123) is of type Octetstring,
  and is defined in [RFC4818].  Within the Tunnel-Source-Pref-Or-Addr
  AVP, it conveys the IPv6 Binding Prefix assigned to the CE.  Valid
  values in the Prefix-Length field are from 0 to 128 (full address),
  although a more restricted range is obviously more reasonable.
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^
I wonder if "obviously more reasonable" is the right thing to say. Is this saying something like "more scalable" (compared to bunches of 128-bit IP binding prefixes)? Or am I misunderstanding the point?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dime-4over6-provisioning-03.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments:

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the AVP Codes registry in the Authentication, Authorization, and Accounting (AAA) Parameters registry at

http://www.iana.org/assignments/aaa-parameters/

15 new AVP codes will be registered as follows:

+-------------------------+-----------------------------+---------------+
| Code | Attribute Name | Reference |
+-------------------------+-----------------------------+---------------+
| [ TBD-at-registration ] | IP-Prefix-Length | [ RFC-to-be ] |
| [ TBD-at-registration ] | Border-Router-Name | [ RFC-to-be ] |
| [ TBD-at-registration ] | 64-Multicast-Attributes | [ RFC-to-be ] |
| [ TBD-at-registration ] | ASM-mPrefix64 | [ RFC-to-be ] |
| [ TBD-at-registration ] | SSM-mPrefix64 | [ RFC-to-be ] |
| [ TBD-at-registration ] | Tunnel-Source-Pref-Or-Addr | [ RFC-to-be ] |
| [ TBD-at-registration ] | Tunnel-Source-IPv6-Address | [ RFC-to-be ] |
| [ TBD-at-registration ] | Port-Set-Identifier | [ RFC-to-be ] |
| [ TBD-at-registration ] | LW4over6-Binding | [ RFC-to-be ] |
| [ TBD-at-registration ] | LW4over6-External-IPv4-Addr | [ RFC-to-be ] |
| [ TBD-at-registration ] | MAP-E-Attributes | [ RFC-to-be ] |
| [ TBD-at-registration ] | MAP-Mesh-Mode | [ RFC-to-be ] |
| [ TBD-at-registration ] | MAP-Mapping-Rule | [ RFC-to-be ] |
| [ TBD-at-registration ] | Rule-IPv4-Addr-Or-Prefix | [ RFC-to-be ] |
| [ TBD-at-registration ] | Rule-IPv6-Prefix | [ RFC-to-be ] |
| [ TBD-at-registration ] | EA-Field-Length | [ RFC-to-be ] |
+-------------------------+-----------------------------+---------------+

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we have initiated the required Expert Review via a separate request, as per our standard procedures. The expert has approved this registration request.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Attribute-Value Pairs For Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions) to Proposed Standard


The IESG has received a request from the Diameter Maintenance and
Extensions WG (dime) to consider the following document:
- 'Attribute-Value Pairs For Provisioning Customer Equipment Supporting
  IPv4-Over-IPv6 Transitional Solutions'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-07-20. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  During the transition from IPv4 to IPv6, customer equipment may have
  to support one of the various transition methods that have been
  defined for carrying IPv4 packets over IPv6.  This document
  enumerates the information that needs to be provisioned on a customer
  edge router to support a list of transition techniques based on
  tunneling IPv4 in IPv6, with a view to defining reusable components
  for a reasonable transition path between these techniques.  To the
  extent that the provisioning is done dynamically, AAA support is
  needed to provide the information to the network server responsible
  for passing the information to the customer equipment.  This document
  specifies Diameter (RFC 6733) attribute-value pairs to be used for
  that purpose.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dime-4over6-provisioning/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dime-4over6-provisioning/ballot/


No IPR declarations have been submitted directly on this I-D.

=== 1. Summary ===

The document shepherd is Lionel Morand.
The responsible Area Director is Kathleen Moriarty.

A AAA infrastructure can be used to provision and configure customer edge devices with subscriber-specific information. This document specifies a set of attribute-value pairs (AVPs) to carry over Diameter authorization information for the configuration of the allowed IPv4-over-IPv6 transition methods for a given user. The following transition techniques have been addressed: DS-Lite, LW4over6, MAP-E and the delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. All these techniques are specified by the Softwire WG.

The approach taken in this document is to define a Grouped AVP (i.e. AVPs nested in a single AVP of type "Grouped") that contains the set of information required for each technique, except for the DS-Lite method for which only one information element is required.

=== 2. Review and Consensus ===

After detailed review and clean-up, this document is ready to be published. Some knowledge on the Diameter base protocol is a prerequisite for the understanding of the definition of the AVPs and implementors will have to rely on the documentations from the Softwire WG to be able to know how to use these AVPs. the related Softwire WG documents are put as normative or informative references when appropriate.

The proposed Diameter extensions definitions are simple (definition of new AVPs in extendable Grouped AVPs), and there was no difficulty in coming to consensus on all points.
As it is only about defining new AVPs, there were no real technical discussion in the WG, considering that the proposed AVP definitions were OK in accordance to the Softwire specifications. Comments received in the meeting or on the mailing list have been taken into account. No concern/comment was received during the WGLC.

The IANA considerations section have been reviewed and is consistent with the body of the document. All protocol extensions are associated with appropriate reservations for IANA. AVP code assignment by IANA should be straightforward.

ID nits tool confirms that document meets the internet drafts checklists.

=== 3. Intellectual Property ===

Each author has confirmed conformance with BCP 78/79.  There are no IPR disclosures on the document.

=== 4. Other Points ===

Two normative references are still in progress:
* I-D.ietf-softwire-lw4over6
* I-D.ietf-softwire-map

As the present specification is only relevant if the above drafts are published as RFCs, the dependency is appropriate.

Three other specifications put as informative reference are still in progress:
* I-D.ietf-softwire-dslite-multicast
* I-D.ietf-softwire-map-dhcp
* I-D.ietf-softwire-multicast-prefix-option
However, there are not essential for this specification.

After additional reviews, the chairs conclude that there is a WG consensus on this document.
Next Step:
- new version of the draft (-02) to take into comments raised after the review.
- Document shepherd  assignment/Write-up
- IESG Submission