Re: [Softwires] WGLC on draft-ietf-softwire-map-radius-14 - 1 of 2

[[e-mail]]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires