On Dec 19, 2022, at 11:53 AM, Rob Wilton (rwilton) <rwilton=40cisco....@dmarc.ietf.org> wrote: > It isn't really clear to me why some of the registries are needed, > specifically the ones in 8.4.1 and 8.4.2. Why not allow any v4 or v6 DHCP > attribute to be carried within the DHCPv6-Options or DHCPv4-Options field?
The original intent of the document was to define a limited set of DHCP options which could be carried in RADIUS. i.e. option X would map to RADIUS attribute Y. After some discussion, this was deemed to be unworkable, and changed to the current method. The previous limitations were still kept, however. While it is useful, I could see issues with allowing any DHCP option to be transported in RADIUS. I'll have to dig deeper to get into details. > > (2) p 4, sec 3. DHCP Options RADIUS Attributes > > Absent any explicit configuration on the DHCP server, RADIUS supplied > data by means of DHCP*-Options Attributes take precedence over any > local configuration. > > This point may be worth discussing. Naturally, I would explicit > configuration to a network device to generally take precedent over implicitly > learned configuration from the network. I'm not sure which options are "implicitly learned" from the network. One set is configured in the device, and another is configured on a per-user / per-session basis. This allows for sane defaults, with specific over-rides where those are needed. If the options configured on the device always take precedence over the per-session options (via RADIUS), then there isn't much point in sending per-session options. > (3) p 6, sec 3.2. DHCPv4-Options Attribute > > Permitted DHCPv4 options in the DHCPv4-Options Attribute are > maintained by IANA in the registry created in Section 8.4.2. > > Comparing this text to the description for v6, this description is silent on > whether multiple instances of the same DHCPv4 option MAY be included. Should > that be specified here? Likely, yes. The RADIUS attributes are simply carrying DHCP options, as if they were in a DHCP packet. So all of the DHCP rules about option handling should apply here. > > (4) p 10, sec 7. Table of Attributes > > The following table provides a guide as what type of RADIUS packets > that may contain these attributes, and in what quantity. > > Am I right that this is just a duplication of what is described in section 3? > If so, perhaps change "guide" to "informative guide" and include text to > refer back to the canonical definition in section 3. Sure. This table is traditional in RADIUS RFCs, so the text here mirrors previous RADIUS RFCs. > (8) p 3, sec 3. DHCP Options RADIUS Attributes > > These attributes use the "Long Extended Type" format in order to > permit the transport of attributes encapsulating more than 253 octets > of data. DHCP options that can be included in the DHCP*-Options > RADIUS attributes are limited by the maximum packet size of 4096 > bytes. In order to accommodate deployments with large options, > implementations are RECOMMENDED to support a packet size up to 65535 > bytes. > > I didn't find this text clear. E.g., limit is 4k but should support up to > 64K. Which implementations should support larger packet sizes? Is this > RADIUS implementations? It's a limitation of RADIUS. Everything RADIUS has to support 4K packets. Later RFCs allow for 64K packets. > > (9) p 5, sec 3.1. DHCPv6-Options Attribute > > This field contains a list of DHCPv6 options. Multiple instances > of the same DHCPv6 option MAY be included. Consistent with > Section 17 of [RFC7227], this document does not impose any option > order when multiple options are present. > > Is there any requirement to merge multiple instances of options together, > presumably they are logically just concatenated today. The rules for DHCP options processing should apply. > (12) p 8, sec 5. Applicability to Encrypted DNS Provisioning > > Figure 1: An Example of RADIUS IPv6 Encrypted DNS Exchange > > As a minor comment, I wonder whether it would be helpful to also include > RADIUS client in the NAS box description? Yes. > > (13) p 12, sec 8.4.1. DHCPv6 > > IANA is requested to create a new sub-registry entitled "DHCPv6 > Options Permitted in the RADIUS DHCPv6-Options Attribute" in the > "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry > [DHCP-RADIUS]. > > Do we need to define the definition of columns for this (and the v4 > equivalent) registries. E.g., do the values need to match another registry? Perhaps just names? It would be good to avoid duplicating multiple columns, as they could get out of sync. Alan DeKok. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
