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

[傅瑜 <[e-mail]>]

Sorry, I forgot to cc the WG last night.


from: <[e-mail]>
sent:2018-04-08 23:03:06
to:[e-mail]
subject: RE: [Softwires] WGLC on draft-ietf-softwire-map-radius-14 - 1 of 2



Hi Ian

 

Thank you very much for you thorough review.

 

Please see my reply inline:

 

Cheers

 

Yu

From:[e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Friday, April 06, 2018 10:59 PM
To: Yong Cui; Softwires WG
Subject: Re: [Softwires] WGLC on draft-ietf-softwire-map-radius-14 - 1 of 2

 

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'

 

[fuyu]: Ok, I will update the title in the next version.

---------

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.

 

[fuyu] Thanks for your suggestion. I will update it.

 

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.  

   

[fuyu] Done

 

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

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.

[fuyu] Done

 

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).

 

[fuyu] Opps, sorry,  my fault.

 

------

 

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.

 

[fuyu] Ok

 

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."

 

[fuyu] Ok, I will update this sentence

 

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.

 

[fuyu] OK, I will remove it.

 

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.

 

[fuyu] I will add a paragraph to describe it.

 

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. 

 

[fuyu] I will add it in the updated version.

 

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.

 

[fuyu] Do you mean to describe device implementation in more detail?

----------------------------

 

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:

 

[fuyu] : I will space out it a bit more. It have already been described the first step after the Figure.

 

  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.

 

[fuyu] I will delete it.

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.

 

[fuyu] Ok, I will delete it.

 

3.h)

s/it should initiate/it initiates/

 

3.i)

s/radius/RADIUS/ - This needs to be done throughout the document.

 

[fuyu] Ok, I will check it throughout.

 

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?)

[fuyu] I will try to reword it in the next version.

 

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)

 

[fuyu] Ok , I will check it again in the next version.

 

A MUST here is also strange. What if the AAA server doesn't have

the requested configuration to supply to the client?

[fuyu]  In the section 4.2 of RFC 2865, it also describes that “If all Attribute values received in an

      Access-Request are acceptable then the RADIUS implementation MUST

      transmit a packet with the Code field set to 2 (Access-Accept).”

So I think a MUST should be here.

 

 

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.

 

[fuyu] Do you mean giving a table to describe DHCPv6 option and corresponding attribute?

 

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?

[fuyu] It is for the IEEE 802.1X Authenticators, the Calling-Station-

Id attribute is used to store the bridge or Access Point MAC address in ASCII format.

I will clarify it in the next version.

 

 

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.

[fuyu]:Ok

 

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).

[fuyu] I will add some description sentence to clarify this.

 

3.s)

The final 3 paragraphs deal with some error handling conditions. Perhaps

a sub-section for these would make for a better structure?

[fuyu] Ok, I will make a sub-section.

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).

 

[fuyu]  I think the key point in the document is to define RADIUS attribute. Shall we need to define this

DHCPv6 scenarios? I think it may be the text which RFC 7598 should include?

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.

[fuyu]: I will add a sub-suction to describe this.