Hi, Here’s my review of the draft. It’s rather long so I’ve had to submit it as two emails. It’s based on -15.
Cheers, Ian Title T.a) RADIUS Attribute for Softwire Address plus Port based Mechanisms To improve readability and as this defines 3 new RADIUS attributes, 'RADIUS Attributes for Address plus Port based Softwire Mechanisms' --------- Abstract: A.a) "IPv4-over-IPv6 transition mechanisms provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period." This isn't really true. The transisition mechanisms don't provide v6 connectivty, they rely on this being there and working. Suggested re-word: IPv4-over-IPv6 transition mechanisms provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existence period. A.b) "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) options have been defined to configure Customer Edge (CE) in MAP-E, MAP-T, Lightweight 4over6 and PREFIX64 option for Multicast Basic Bridging BroadBand (mB4) in multicast scenarios. " Suggested re-word for readability: DHCPv6 options have been defined for configuring clients to use MAP-E, MAP-T, Lightweight 4over6 and Multicast Basic Bridging BroadBand (mB4) in multicast scenarios. A.c) The abstract has both the expanded and abbrieviated form of a few terms (e.g. BNG). These definitions are also repeated later in the introduction. As these terms are defined in the IETF acronyms list https://www.rfc-editor.org/materials/abbrev.expansion.txt <https://www.rfc-editor.org/materials/abbrev.expansion.txt> there's no need to provide these definitions, just the acronyms would be OK. As a suggestion for readability - DHCPv6, RADIUS, AAA, and BNG are well known so don't need the expanded form. mB4 is less well known, so the expanded version is more helpful. The repetitions of the definitions in the Introduction can be removed. A.d) "This document defines two new Remote Authentication Dial In User Service (RADIUS) attributes that carry CE or mB4 configuration information from an AAA server to BNG." There's actually 3 new attributes in the draft (Softwire46-Priority is missing). ------ 1. Introduction 1.a) It would simplify the overall readibility of the document to define the MAP-E, MAP-T and lw4o6 (i.e. RFC7598 configured) softwires as 'unicast' and the RFC8114 as multicast in the Intro. This would avoid the need to list MAP-E, MAP-T... etc. throughout. 1.b) s/Recently providers/Recently, providers/ 1.c) s/started to deploy IPv6 and consider how to transit to IPv6./ started deployment and transition to IPv6./ 1.d) "In particualr, the CE uses DHCPv6 options to discover the Border Relay (BR) and retrieve Softwire46 (S46) configurations." This is one way that configuration can be done - there's also a YANG model in development and DHCPv4o6 provisioning. It would be more accurate to say: "[RFC7598] defines DHCPv6 options for provisioning CEs for unicast softwires." 1.e) For the mutlicast section, all of the fields that are present in OPTION_V6_PREFIX64 are described in full, but this is not done for the unicast equivalents. It would make sense to be uniform between the two, but if all of the options/sub-options from RFC7598 get included, then it's going to get pretty long. I think it would improve the consistency and readability without brining in large amounts of duplication to remove the text starting 'The following lists the multicast-related information...' upto (and including) the Unicast Prefix64 description. In it's place, a paragraph describing the relationship between this document and RFC7598/8115 could be added, referencing the relevant sections in those RFCs that the fields are defined. 1.f) After the sentence "A DHCPv6 server function is assumed to be embedded in the BNG that allows it to locally handle any DHCPv6 requests initiated by hosts." it would be worth adding that the term BNG is used througout the document to describe a device which functions as both the AAA client and DHCPv6 server. 1.g) s/MAP-E[RFC7597], MAP-T[RFC7599] and Lightweight 4over6[RFC7596]/ MAP-E [RFC7597], MAP-T [RFC7599] and Lightweight 4over6 [RFC7596]/ 1.h) s/options[RFC7598]/options [RFC7598]/ 1.i) Last paragraph: It would also be worth saying how the structure of the DHCP options and field namings are preserved so they can easily be mapped between DHCP and RADIUS. ---------------------------- 3. Configuration Process with RADIUS 3.a) s/CE with MAP/CE with softwire/ 3.b) s/how the RADIUS protocol and DHCPv6 co-operate/how the RADIUS and DHCPv6 protocols co-operate/ 3.c) The figure is easier to follow if it is space out a bit more and clafifies the first step: CE BNG AAA Server | | | |-------1.DHCPv6 Solicit------->| | |(ORO with unicast and/or m'cast| | | container option code(s)) | | | | | | |-------2.Access-Request------->| | | (S46-Configuration attribute | | |and/or S46-Multicast attribute)| | | | | |<------3.Access-Accept---------| | | (S46-Configuration attribute | | |and/or S46-Multicast attribute)| | | | |<----4.DHCPv6 Advertisement----| | | (container option(s)) | | | | | |-------5.DHCPv6 Request------>| | | (container Option(s)) | | | | | |<--------6.DHCPv6 Reply--------| | | (container option(s)) | | | | | DHCPv6 RADIUS 3.d) s/1. First, the CE may initiate a DHCPv6 Solicit/For unicast, the CE initiates a DHCPv6 Solicit/ 3.e) Citing the relevant RFC number after every term makes it more difficult to read. As these are already referenced earlier in the document, they don't need to be repeated here. 3.f) Replace: For the multicast case, OPTION_V6_PREFIX64 should be included for the delivery of multicast services in the context of transition to IPv6. with: For the multicast case, the the option number for OPTION_V6_PREFIX64 (113) should be included in the client's ORO. 3.g) "Note however, that the ORO (Option Request option) with the S46 Container option code could be optional if the network was planned to be S46-enabled by default." As this is a RADIUS specification, this sentance can be removed. 3.h) s/it should initiate/it initiates/ 3.i) s/radius/RADIUS/ - This needs to be done throughout the document. 3.j) s/a User-Name attribute (1) should be filled by a CE MAC address or interface-id or both. This message will be sent to the RADIUS server./a User-Name attribute (1) is completed with either a CE MAC address, interface-id or both and sent to the RADIUS server./ 3.k) This paragraph is a little hard to follow: 2. When the BNG receives the Solicit message, it should initiate a radius Access-Request message. In this message, a User-Name attribute (1) should be filled by a CE MAC address or interface-id or both. This message will be sent to the RADIUS server. In this message, a User-password attribute (2) should be filled by the shared password that has been preconfigured on the DHCPv6 server, requesting authentication as defined in [RFC2865] with the corresponding Softwire46-Configuration Attribute or Softwire46-Multicast Attribute. The Softwire46-Configuration Attribute and Softwire46-Multicast Attribute will be defined in the next Section. Suggested re-word (also are all of teh attributes necessary? Are any optional?) 2, When the BNG receives the Solicit message, it should initiate a RADIUS Access-Request message continaing: A User-Name attribute (1) (with either a CE MAC address, interface-id or both), a User-password attribute (2) (with a pre-configured shared password as defined in [RFC2865]), and the Softwire46-Configuration Attribute and/or Softwire46-Multicast Attribute (as reuquested by the client). The resulting message is sent to the RADIUS server. 3.l) Item 3. uses an RFC2119 MUST statement. This is the first time in the message flow that any compulsory behaviour is defined. The requirements language should be consitent throughout all of the steps (either all RFC2119, or none) A MUST here is also strange. What if the AAA server doesn't have the requested configuration to supply to the client? 3.m) In the DHCPv6 Advertisement message, there needs to be the corresponding DHCPv6 option holding the correct information from the RADIUS message. This means that we need to map the fields from the attributes to the options. A table showing how this mapping is done would be very useful. 3.n) Suggested re-word: old: 5. After receiving the Advertise message, the CE MAY request for the corresponding S46 Container Option, by including the S46 Container option in the Request message. new: 5. On receipt of an Advertise message containing one or more of the requested DHCPv6 softwire container options (94, 95, 96, or 113) the CE MAY request configuration for the desired softwire mechanism(s) by including the option code(s) in the ORO of the DHCPv6 Request message. 3.o) Suggested re-word: old: 6. After receiving the client's Request message, containing the corresponding S46 Container option, the BNG SHOULD reply to the CE with the message containing the S46 Container option. new: 6. When the BNG receives the client's DHCPv6 Request message, it constructs a Reply message containing the softwire container options enumerated in the ORO. 3.p) "The recommended format of the MAC address is defined as Calling-Station- Id (Section 3.20 in [RFC3580] without the SSID (Service Set Identifier) portion." I don't understand the meaning of this sentence in context of where we are in the message flow. What is the MAC address that is needed at this stage? 3.q) Suggested re-word: For Lightweight 4over6 [RFC7596], the subscriber's binding state should be synchronized between the AAA server and lwAFTR. If the bindings are pre-configured statically in both the AAA server and lwAFTR, an AAA server does not need to configure the lwAFTR anymore. Otherwise, if the bindings are locally created on-demand in an AAA server, it should inform the lwAFTR with the subscriber's binding state, in order to synchronize the binding information of the lwB4 with the lwAFTR. with: For Lightweight 4over6 [RFC7596], the subscriber's binding state needs to be synchronized between the clients and the lwAFTR. This can be achieved in two ways: pre-configuring the bindings statically 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. 3.r) The paragraph begining "The authorization process could also..." doesn't really make sense where it is located. The previous paragraph does not follow from the previous para. concerning lw4o6 syncronisation and refers to a previous scenario, although it's not really clear what that scenario is. This could be cleared up by (1) making it clear that section 3 fig 1. is describing combined Authentication and Authorisation. (2) Creating a sub-section for this paragraph (and the one below it) that detail what the changes are from the steps in section 3 (i.e. where additional attributes are needed / not needed and what they contain). 3.s) The final 3 paragraphs deal with some error handling conditions. Perhaps a sub-section for these would make for a better structure? 3.t) What happens if steps 1-4 complete, but the BNG never receives a request message from the client? In this case, the AAA has allocated resources, but they are not actually in use. Is there a way that the BNG can invalidate the request after a timeout, or is there another error handling mechanism that should be used? 3.u) There's no text on what happens when the client send a DHCPv6 Release, Decline, or an associtated DHCPv6 lease expires (invalidating any options supplied with that lease). 3.v) As this section is describing how the different attrributes are requested and used, it would be worth also having a sub-section concerned with the interaction of Softwire46-Priority Attribute and RFC8026. > On 26. Mar 2018, at 15:43, Yong Cui <cuiy...@tsinghua.edu.cn> wrote: > > Hi folks, > > The authors of draft-ietf-softwire-map-radius-14 believe this document is > ready for advancement. > We would like to issue a working group last call starting from today to April > 9th. > > Please send your substantial comments to the list during the last call. You > are also welcome to send your editorial comments directly to the authors. > > Thanks for reviewing the draft. > > > Yong Cui and Ian Farrer > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires