RADIUS Attributes for Softwire Mechanisms Based on Address plus Port (A+P)
RFC 8658

A few editorial nits:

-- Section 3.  Per “Depending on the deployment scenario …”, this sentence doesn’t parse for me.  I think s/so// would address it.

-- Section 3.1.4.2.  Typo.  s/pecifies/specifies/

Much thanks to Al Morton for his OpsDir review -- it was very helpful, and I'm balloting NoObj based on it.

This is a fine document. I have one small question:

In 3.1:

      The Softwire46-Configuration Attribute MUST only encapsulate one
      or more of the Softwire46 attributes defined in this document.

This reads to me that only attributes defined in this document can be encapsulated.
Does this make this attribute deliberately non extensible? You have created various IANA registries, which makes me wonder whether this was intentional.

I have a couple of (mostly) process notes:

(1) A Normative Reference to rfc5176 was added during IETF LC, resulting in a Downref not called out during the LC.  rfc5176 has been used before as a Downref, so I don't think this is a very big deal (nor that a new LC is needed), but I'll leave that decision to the Responsible AD.  [It may be time to update the Downref registry.]

(2) Section 9 (Acknowledgements) includes this text:

   This document was merged with draft-sun-softwire-lw4over6-radext-01
   and draft-wang-radext-multicast-radius-ext-00, thanks to everyone who
   contributed to this document.

But there are no formal References to either document -- an Informative one should me included.  Also, the datatracker page for the document doesn't reflect the relationship.

It might be worth a brief note somewhere about why attributes of this
sort can be included in Accounting-Request packets (and, to a lesser
extent, CoA-Request packets).

Section 1

   Since IPv4-in-IPv6 softwire configuration information is stored in an
   AAA server, and user configuration information is mainly transmitted
   through DHCPv6 between the BNGs and Customer Premises Equipment (CEs,
   a.k.a., CPE), new RADIUS attributes are needed to propagate the
   information from the AAA servers to BNGs.

nit: maybe "from the AAA servers to BNGs so that they can be propagated
to CPE over the existing DHCPv6 options."?

Section 2

Please use the boilerplate text from RFC 8174 (including BCP 14
mention).

Section 3.1

      The Softwire46-Configuration Attribute conveys the configuration
      information for MAP-E, MAP-T, or Lightweight 4over6.  The BNG
      SHALL use the configuration information returned in the RADIUS
      attribute to populate the DHCPv6 Softwire46 Container Option
      defined in Section 5 of [RFC7598].

nit: "Option(s)" seems more appropriate, since that section defines
separate options for MAP-E and MAP-T.

Section 3.1.1.1

Just to double-check my understanding: since this is an "attribute",
it's a top-level container with the 'type' value bearing universal
semantics for all RADIUS packets, as opposed to a "tlv" that appears
within a given attribute and whose 'type' values only have meaning in
the context of that attribute?  But this interpretation doesn't hold up
for (e.g.) Section 3.3.3, which defines an "attribute" but uses a
"TLV-Type" that is in the range of values scoped only to the structures
defined in this document.

Section 3.1.3.2

   There MUST be at least one Softwire46-BR included in each
   Softwire46-MAP-E or Softwire46-Lightweight-4over6.

This seems to be in conflict with Table 2, which says that exactly one
Softwire-BR is included in each MAP-E or Lightweight-4over6 attribute.

Section 3.1.6.1

                         This field that specifies the
         numeric value for the Softwire46 algorithm's excluded
         port range/offset bits (a bits), as per Section 5.1
         of [RFC7597]. Allowed values are between 0 and 15.

nit: "This field that specifies" is redundant; just "This field
specifies" would be  fine.

I'm also not sure I understand the range being between 0 and 15, when we
previously talk about this being an 8-bit value ("right justified").

Section 3.1.6.3

This format seems needlessly confusing.  We encode as an integer (32-bit
unsigned), but then state that this 32-bit integer contains a 16-bit
value, right justified.  And then we only interpret the f irst 'k' bits
on the left of the 16-bit value.  Isn't there a simpler way to encode a
'k' bit value in a 32-bit field?

Section 3.2

          Softwire46 mechanisms are prioritized in the appearance order
          of the in the Softwire46-Priority Attribute.

Do we want to say explicitly that the first-appearing mechanism is most
preferred?

Section 3.3.1

    TLV-Length
       16 octets. The length of asm-prefix64 must be to 96 [RFC8115].

nit(?): I can't parse the grammar here -- what does "must be to" mean?
(Same question for following section.)

Please expand "ASM" on first use.

Section 4

   1.  The CE creates a DHCPv6 Solicit message.  For unicast softwire
       configuration, the message includes an OPTION_REQUEST_OPTION (6)
       with the Softwire46 Container option codes as defined in
       [RFC7598].  [...]

nit: with all of them (the Softwire46 Container option codes)?

   2.  On receipt of the Solicit message, the BNG constructs a RADIUS
       Access-Request message containing a User-Name Attribute (1)
       (containing either a CE MAC address, interface-id or both), a
       User-Password Attribute (2) (with a pre-configured shared
       password as defined in [RFC2865].  The Softwire46-Configuration
       Attribute and/or Softwire46-Multicast Attribute are also included
       (as requested by the client).  The resulting message is sent to
       the AAA server.

Perhaps clarify whether the shared password is shared between BNG/AAA
server, or CE/AAA server?

   6.  The BNG sends a Reply message to the client containing the
       softwire container options enumerated in the ORO.

nit: maybe "DHCPv6 Reply" to match the "DHCPv6 Request" in step (5)?

   The authorization operation could also be done independently, after
   the authentication process.  In this case, steps 1-5 are completed as
   above, then the following steps are performed:

nit: "authorization" or "authorize" do not appear in the previous
procedure anywhere; it would be rhetorically more clear what this
statement refers to if there was explicit mention in the prior
procedure.

   o  In both the configuration message flows described above the
      Message-authenticator (type 80) [RFC2869] SHOULD be used to
      protect both Access-Request and Access-Accept messages.

Why is this SHOULD and not MUST?  Maybe an example of when it would not
be needed would be helpful?
nit: Message-Authenticator has two capital letters.

   o  As specified in [RFC8415], Section 18.2.5, "Creation and
      Transmission of Rebind Messages", if the DHCPv6 server to which
      the DHCPv6 Renew message was sent at time T1 has not responded by
      time T2, the CE (DHCPv6 client) SHOULD enter the Rebind state and
      attempt to contact any available server.  In this situation, a

This seems to just be restating the requiremnets from RFC 8415, in which
case the normative language is not needed...

      secondary BNG receiving the DHCPv6 message MUST initiate a new
      Access-Request message towards the AAA server.  The secondary BNG
      includes the Softwire46-Configuration Attribute in this Access-
      Request message.

... but this MUST does need to use normative language (as it currently
does).

   o  For Lightweight 4over6, the subscriber's binding state needs to be
      synchronized between the clients and the Lightweight AFTR
      (lwAFTR)/BR.  This can be achieved in two ways: static pre-

We have not previously talked about the "subscriber"; is there some
realignment of terminology or earlier definition that would help clarify
how the subscriber relates to the other entities in play?

      configuration of the bindings on both the AAA server and lwAFTR,
      or on-demand whereby the AAA server updates the lwAFTR with the
      subscriber's binding state as it is created or deleted.

(I assume this is done "out of band" from the perspective of this
document.)

Section 6

As the secdir reviewer notes, there are a lot of references here.
That's usually good, avoiding duplication of content/etc., but this text
seems to claim that there is discussion of known security
vulnerabilities in RADIUS discussed in RFCs 2607, 2865, and 2869, and a
quick review of those documents does not find extensive discussion of
such vulnerabilities (and not much in the Security Considerations
section where one might expect to find it).  I think that just those
references may not provide a comprehensive picture of the state of
RADIUS (in)security, and so some additional exposition to tie together
what those documents are saying (including Section references as
appropriate), as well as potential other information, would be in order.
I note that there was some fairly recent discussion of the general state
of RADIUS security in the IESG processing of
draft-ietf-radext-coa-proxy, along the lines of "it basically boils down
to you have to trust your neighbor/contractual arrangement".  I do *not*
think that the three RFCs from 2000 convey that sentiment well, and so
the following paragraph's statement about targetting deployments with a
trust relationship is quite important.  Perhaps we can tweak the writing
a bit so that these two points tie together more clearly.

It may be worth mentioning earlier (in the Introduction?) that this
document only targets deployments with a trusted relationship between
RADIUS client/server (that can use IPsec/TLS as appropriate).

I am also not entirely sure about the "does not introduce any security
issue other than the ones already identified in RADIUS documents",
though admittedly the additional exposure seems quite minimal.
Specifcally, without these RADIUS attributes, DHCPv6 negotiation of
softwires includes in-band protocol flows conveying softwire
configuration information between DHCP client and BNG, but now that
information flows additionally to the AAA server.  The additional
exposure seems minimal, though, since the necessary softwire
configuration information inherently needs to be in *some* central
location, so we're just exchanging one way of configuring the BNG ("out
of band") for another (RADIUS).  The most notable difference would seem
to be that now we have to trust the AAA server to not leak the softwire
configuration details (as opposed to whatever central configuration
server would otherwise be used), but since both are rather inherently
trusted roles, there's not in the general case more attack surface to
worry about.

Section 7.3

If the registry is to be "Option Codes Permitted in the
Softwire46-Priority Attribute", that seems to imply that there are some
option codes *not* permitted.  Where are those option codes enumerated?
(I would have guessed at
https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2
, but the values don't seem to match up.)  Do we need to add a note
somewhere about future allocations of such option codes needing to
decide whether or not they are permitted in the Softwire46-Priority
Attritube?

Editorial: In section 4 I would recommend to maybe move the points to consider at the end to its own section, as these contain normative requirements and could be overlooked if one skips over the example.

Also on this specifically:
“As specified in [RFC8415], Section 18.2.5, "Creation and
      Transmission of Rebind Messages", if the DHCPv6 server to which
      the DHCPv6 Renew message was sent at time T1 has not responded by
      time T2, the CE (DHCPv6 client) SHOULD enter the Rebind state and
      attempt to contact any available server.  In this situation, a
      secondary BNG receiving the DHCPv6 message MUST initiate a new
      Access-Request message towards the AAA server. “
If this is normatively specified in RFC8415, I recommend to not use normative language here. However, I didn’t check the wording in RFC8415…

Thanks for addressing my DISCUSS and COMMENT.