Subject: [Softwires] Fwd: I-D Action: draft-ietf-softwire-map-radius-16.txt

From: [email-masked]
Date: Fri, 20 Jul 2018 10:30:20 +0200

Forwarding to the list.

Hi Yu,

Thanks for the update. I think the changes that you have made have improved the document significantly, but there’s still a few things that need to be addressed. Please see below.

Also, Jordi asked a question about this draft, which I don’t think has been replied to:
https://mailarchive.ietf.org/arch/msg/softwires/_7ocUxBwy9i2UqNj2tzqri9p0Gw <https://mailarchive.ietf.org/arch/msg/softwires/_7ocUxBwy9i2UqNj2tzqri9p0Gw>

Thanks,
Ian

New comments on -16:

Throughout - the use of 'Sub TLV' and 'Sub-TLV' is not consistent.
Sub-TLV seems to be the convention in other RFCs (e.g. RFC6929).

Introduction.

s/At the Section 4.9/In Section 4.9/

As the softwire prioritisation funciton of RFC8026 is also
included, there should be a short paragraph (a cut down version of
sec 4, para 3) stating that this function is included.

Section 3, point 6.

In the diagram, you show a simple reply message being sent
to the client, but the accompanying text describes a number
of other communication flows and updates that can potentially
need to happen.

Really, the whole of this section is not really well constructed
in it's current form. The purpose of the numbered points is to
describe what is in the flows in the diagram, but point 6. goes
on to included a further page and a half of options and
considerations. Can point 6 not be ended after the sentance ending
...enumerated in the ORO.? and the remaining text in section 3
be put into relevantly named sub-sections.

4.4.2 S46-BR Sub TLV
S46-Lightweight--4over6 TLV - please remove duplicate '-'.

4.5 Sub-TLVs for S46-Rule Sub TLV
Given the RFC2119 language used in the requirements for the
other options, suggest the following:
s/It should appear for once and only once./It MUST appear
exactly once./

4.6.2 The Bind-IPv6-Prefix Sub-TLV

s/The bind-ipv6-prefix field specified in this field/The bind-ipv6-prefix specified in this field/

---------

Updated comments from my previous review:

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.

[if - New version is better, but a suggested rewording for these two sentances:
A DHCPv6 server function is assumed to be embedded in the BNG
that allows it to locally handle DHCPv6 requests initiated by
hosts.  The abbrieviation BNG is used in this document to describe a device
which functions as both the AAA client and DHCPv6 sever.]

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.

[if - I can't find any changes in the text for this, or any repsonse
to the comment.]

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

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

[if - Old diagram is still present, please use the above figure.]

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.

[if - Sorry, I doubled the word 'the' in my suggested text. Please use 'case,
the option number']

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?

[if - Sorry, I doubled the word 'the' in my suggested text. Please use 'case,
the option number']

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.

[if - I can't find any changes in the text for this, or any repsonse
to the comment.]

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?

[if - The addtional text doesn't answer this question. The BNG is constructing
a DHCPv6 Reply message. Where does a MAC address belong in this message?
If it's the MAC address that it will source the DHCPv6 reply message from,
why is it being changed at this stage rather than configured in advance (i.e.
before the Advertise is sent) so it can be consistent throughout the
whole DHCP message flow?]

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

[if - Currently still a problem, please see my general comments on
this version above.]

3.s)
The final 3 paragraphs deal with some error handling conditions. Perhaps
a sub-section for these would make for a better structure?

[if - The error handling text is now duplicated, once with
bullet points and again in the body text. Please fix.]

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

[if - I can't find any changes in the text for this, or any repsonse
to the comment.]

On 26. Jun 2018, at 10:54, Yu Fu <[email-masked]> wrote:

Hi Ian,

Sorry to update the 16 version of this draft a little late.

It takes me a long long time to redesign the format of
Softwire46-Configuration Attribute and Priority Attribute and the nested
TLVS according to the RFC6929 and RFC8044.
And it also takes me a long time to double check the new formatting and the
hierarchy of the nested TLVs.

The main changes for this version are as followed base on your comments from
WGLC.

1) As your suggested, it divided the Figure 2 into 3 diagrams (one for each
type) for MAP-E, MAP-T, and Lightweight 4over6.
So it can make the Figure 2 more clear to show which TLV is necessary and
which is optional.

2) It makes a common format for the definitions of which RADIUS messages
types the Softwire46-configuration/ Priority /multicast attributes can
appear in the section 4.1 and 4.8.

3) It changes the description text and formatting of the
Softwire46-configuration/ Priority attribute according to the RFC6929 and
RFC8044 so as to consistent with the format of Softwire46-multicast
attribute.

4) The IANA Consideration has been rewritten so that it will be more clear
for the assignment of the Attribute Types and new RADIUS TLVs.

5) Some grammar mistakes and typos have been corrected.

Your valuable comments are appreciated.

Thanks
Yu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Tuesday, June 26, 2018 3:59 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Softwires] I-D Action: draft-ietf-softwire-map-radius-16.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Softwires WG of the IETF.

      Title           : RADIUS Attributes for Address plus Port based
Softwire Mechanisms
      Authors         : Sheng Jiang
                        Yu Fu
                        Bing Liu
                        Peter Deacon
                        Chongfeng Xie
                        Tianxiang Li
                        Mohamed Boucadair
	Filename        : draft-ietf-softwire-map-radius-16.txt
	Pages           : 37
	Date            : 2018-06-26

Abstract:
 IPv4-over-IPv6 transition mechanisms provide both IPv4 and IPv6
 connectivity services simultaneously during the IPv4/IPv6 co-
 existence period.  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.  However, in many
 networks, the configuration information may be stored in an AAA
 server, while user configuration information is mainly provided by
 the BNG through the DHCPv6 protocol.  This document defines three new
 RADIUS attributes that carry CE or mB4 configuration information from
 an AAA server to BNG.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-softwire-map-radius/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-softwire-map-radius-16
https://datatracker.ietf.org/doc/html/draft-ietf-softwire-map-radius-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-radius-16

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires