Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt

From: Wojciech Dec <[email-masked]>
Date: Thu, 08 Mar 2012 18:17:43 +0100

Hello Chairs, all,

Would appreciate WG feedback on how to handle the comment(s). On
the one hand, the current format of the attribute represents the result of
consented previous WG feedback, on the other it is not in line with more
recent recommendations in RFC6158.

Thanks,
Woj.

> 
> ------ Forwarded Message
> From: Leaf yeh <[email-masked]>
> Date: Thu, 16 Feb 2012 12:05:44 +0000
> To: Wojciech Dec <[email-masked]>, Bernard Aboba <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]"
> <[email-masked]>, Stefan Winter <[email-masked]>
> Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt
> 
> Wojciech - the Route-IPv6-Information attribute changed from its
> previous "non complex" to the current form between draft 04 and 05, based on
> WG review/feedback:
> http://trac.tools.ietf.org/wg/radext/trac/ticket/71
> 
> 
> As per the requirement in the section 2.1 of RFC6158,
> 
> <quote>Since there are no "hard and fast"
> rules for where complexity is best located, each situation has to be
> decided on a case-by-case basis...Where a complex data type is selected, an
> explanation SHOULD be offered as to why this was necessary.</quote>
> 
> would you clarify the reason for the adoption of the 'complex data type' in
> the definition of attribute, Route-IPv6-Information?
> 
> I can¹t find the answer in the following links:
> http://trac.tools.ietf.org/wg/radext/trac/ticket/71 &
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-radext-ipv6-access-05 .
> 
> The definition of the attribute without multi-fields sounds 'ok' with me
> personally, but RFC6158 (& its section A.2.1) seems not recommended it.
> 
> Is my understanding right here?
> 
> 
> Best Regards,
> Leaf
> 
> 
> -----Original Message-----
> From: Wojciech Dec [mailto:[email-masked]]
> Sent: Wednesday, February 15, 2012 8:24 PM
> To: Alan DeKok; Leaf yeh
> Cc: [email-masked]; Stefan Winter; [email-masked]
> Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt
> 
> Just as an FYI, the Route-IPv6-Information attribute changed from its
> previous "non complex" to the current form between draft 04 and 05, based on
> WG review/feedback:
> http://trac.tools.ietf.org/wg/radext/trac/ticket/71
> 
> -Wojciech.
> 
> 
> 
> On 15/02/2012 13:05, "Alan DeKok" <[email-masked]> wrote:
> 
>> Leaf yeh wrote:
>>> After reading and employed the RFC6158, Radius Design Guidelines, could it
>>> be
>>> concluded the attribute of Route-IPv6-Information defined in the
>>> draft-ietf-radext-ipv6-access-06 shown as follows:
>> ..
>>> is creating a new 'Complex Data Type', which has multi-fields, and is not
>>> recommended? 
>> 
>>   That is what the document says.
>> 
>>> Will it get the same 'acceptable' as that of Frame-IPv6-Prefix (97) and
>>> Delegated-IPv6-Prefix(123), which is mentioned in Section B.7 of RFC6158?
>> 
>>   No.
>> 
>>   I could explain here, but there's no need.  Read RFC 6158.  It
>> thoroughly details the rationale behind the design guidelines.
>> 
>>   Alan DeKok.
> 
> _______________________________________________
radext mailing
> list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext

> 
> ------ End of Forwarded Message

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

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 08 Mar 2012 18:17:43 +0100

Hello Chairs, all,

Thanks,
Woj.

radext mailing
[email-masked]

---

From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
Date: Tue, 13 Mar 2012 17:09:05 +0000

RADEXT, like any good IETF WG, has a colorful history and sometimes a bit
schizophrenic, as this particular case can attest to.  I think we can all
agree that the ipv6 attributed noted below is of a complex type and in
conflict with RFC6158 mandate to not continue to promulgate such complex
types. However, RFC6158 also includes a significant amount of leeway.  I
think we have two options before us:

(1) Per RFC6158's mandate include a small statement justifying the complex
attribute as it stands now.  Statement would be similar in spirit to what
appendix B in RFC6158 does for other complex attributes

(2) Recast the design of attribute into a new form that reduces its
complexity (i.e. Look to follow RFC6158 more closely).

If we agree these are the two options before us, we can do consensus check
on which approach the WG would like to take.

-MS

---

From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
Date: Tue, 13 Mar 2012 17:09:05 +0000

-MS

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 14 Mar 2012 10:58:34 +0100

Personally, I'm ok either way, but perhaps in the wider interest of closing off on the draft sooner rather than later I'd vote for (1). What about the rest of the WG?

Regards,
Woj.

> From: Sanchez, Mauricio (HP Networking)
> [mailto:[email-masked]]
> Sent: 13 March 2012 18:09
> To: Wojciech Dec (wdec); [email-masked]
> Cc: Bernard Aboba; [email-masked]
> >>>> is creating a new 'Complex Data Type', which has multi-fields, and
> is
> >>>>not
> >>>> recommended?
> >>>
> >>>> Will it get the same 'acceptable' as that of Frame-IPv6-Prefix
> (97)
> >>>>and

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 14 Mar 2012 10:58:34 +0100

Regards,
Woj.

---

From: Peter Deacon <[email-masked]>
Date: Wed, 14 Mar 2012 10:26:14 -0700 (Pacific Daylight Time)

On Wed, 14 Mar 2012, Wojciech Dec (wdec) wrote:

> Personally, I'm ok either way, but perhaps in the wider interest of 
> closing off on the draft sooner rather than later I'd vote for (1). What 
> about the rest of the WG?

What is the purpose of signaling lifetime and preference via RADIUS? 
Could the NAS better handle these parameters intelligently and or with 
local configuration?

If necessary it seems the NAS would have the capability to issue zero 
lifetime advertisements to invalidate current routes in order to effect 
routing changes as a result of session reauthorization.

Currently I prefer -04 version as I'm not seeing the value justify cost of 
another custom packet format for one attribute.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Wed, 14 Mar 2012 10:26:14 -0700 (Pacific Daylight Time)

regards,
Peter

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 14 Mar 2012 18:36:39 +0100

> Could the NAS better handle these parameters intelligently and or with

That was the original idea... Countered with the argument that the fuller
parameters should also be exposed, since they all relate to info sent in a
RA.

Looking at it from another angle, that of a dhcp-pd, we see that while the
prefix has its own attribute it does not expose any/all dhcp timers, values
etc in radius. Ie the equivalent of the -04 version.
> another custom packet format for one attribute.

Given that the fix to go back to -04 is also trivial, I'd be happy with
that.

-Woj.

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 14 Mar 2012 18:36:39 +0100

-Woj.

---

From: jouni korhonen <[email-masked]>
Date: Thu, 15 Mar 2012 00:19:24 +0200

> etc in radius. Ie the equivalent of the -04 version.

RFC3162 Framed-IPv6-Prefix content that gets put into PIO does not either
have anything else but the prefix and its length.

> Given that the fix to go back to -04 is also trivial, I'd be happy with

I would be happy to go back to -04 with this specific attribute as well.

- Jouni

---

From: jouni korhonen <[email-masked]>
Date: Thu, 15 Mar 2012 00:19:24 +0200

- Jouni

---

From: Leaf yeh <[email-masked]>
Date: Fri, 16 Mar 2012 02:46:47 +0000

If the format of 'Route-IPv6-Information' is designed as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |    Length     |   Reserved    | Prefix-Length |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                        Prefix (variable)                      .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

which is quoted from http://tools.ietf.org/id/draft-ietf-radext-ipv6-access-04.txt, it sounds we only care to the corresponding route sent to the user hosts through RA.

Then I begin to doubt the necessity of the network scenario, where the RG or host are expected to be multi-homed to both NASes, which shows as:

                                                   +-----+
                                        (Radius)   | AAA |
                                       ...........>|     |
                                       .           +--+--+
                                       v              ^
                                   +---+---+          .
                                   |  NAS  |          .(Radius)
                                   |       |          .
                                   +---+---+          v
                    +------+           |          +---+---+
     +------+       |  AN  |           |          |  NAS  |
     |  RG/ +-------|      +-----------+----------+       |
     | host |       |      |                      |       |
     +------+ (DSL) +------+      (Ethernet)      +-------+

                              Figure 1

I guess Figure 1 could be simplified as:

                                                   +-----+
                                                   | AAA |
                                                   |     |
                                                   +--+--+
                                                      ^
                                                      .
                                                      .(Radius)
                                                      .
                                                      v
                    +------+                      +---+---+
     +------+       |  AN  |                      |  NAS  |
     |  RG/ +-------|      +-----------+----------+       |
     | host |       |      |                      |       |
     +------+ (DSL) +------+      (Ethernet)      +-------+

Otherwise, we might need some text for the reasons or description why we keep the information of 'Route Preference' (or even 'Router Lifetime')  to meet the requirement from RFC4191. Right? 

I am interested in the value of multi-home connecting to the NASes in the network architecture originally shown in Figure 1, I guess the 'Route Preference' for the default router of the user host might be useful in this case.

Best Regards,
Leaf

________________________________________
From: [email-masked] [[email-masked]] on behalf of jouni korhonen [[email-masked]]
Sent: Thursday, March 15, 2012 6:19
To: Wojciech Dec
Cc: Bernard Aboba; [email-masked]; Sanchez, Mauricio (HP Networking); Peter Deacon
Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt

- Jouni

---

From: Leaf yeh <[email-masked]>
Date: Fri, 16 Mar 2012 02:46:47 +0000

0                   1                   2                   3

                                                   +-----+
                                        (Radius)   | AAA |
                                       ...........>|     |
                                       .           +--+--+
                                       v              ^
                                   +---+---+          .
                                   |  NAS  |          .(Radius)
                                   |       |          .
                                   +---+---+          v
                    +------+           |          +---+---+

                              Figure 1

                                                   +-----+
                                                   | AAA |
                                                   |     |
                                                   +--+--+
                                                      ^
                                                      .
                                                      .(Radius)
                                                      .
                                                      v
                    +------+                      +---+---+
     +------+       |  AN  |                      |  NAS  |

Best Regards,
Leaf

- Jouni