Re: [mif] Route option for DHCPv6 - next steps?

[Tao Sun <[e-mail]>]

People argued quite a lot that RS/RA can be used for the problem. It can be
seen that only rely on the RA based solution, the RA, Radius or even
protocols such as PMIP need to do enhancement or extension.



DHCPv6 option provides more easy way to implement in practice. This makes
the route configuration for multiple interface more easily adopted. Only
put all the hope to the RA related enhancement may prevent operators adopt
this functionality. In the end, neither RA nor DHCPv6 option may be used,
which may delay or even prevent the feature that a host can simultaneous
access through multiple interfaces.

Tao Sun

On Tue, Apr 10, 2012 at 11:09 PM, Wojciech Dec <[e-mail]> wrote:

> Folks,
>
> before we get carried away on the "let's use Radius to provision the edge
> router" solution, allow me to say that:
> a) this is already standardized if not actually practised today
> b) it does not solve the problem of the operators who do not directly
> control the access edge router (eg think wholesale)
> c) it requires not only a specific type of Radius infrastructure, that
> some operators choose not to have, but also a specific type of stateful NAS
> router (eg a BRAS) that others still also do not want to have.
>
> Beyond the above, and in much the same way as has been argued previously,
> a Radius client on the end device solution variant could also be used to
> provision the route on the client (or SNMP, or a script, etc).
>
> In theory thus, all of the Radius variants, are all perfectly good
> solutions, and standards based too. The practicality of them is a different
> matter, and this problem is all about per host configuration and
> operational practicality. At least personally, I humbly think that there is
> no one size fits all solution in this domain, and "perfectly good
> theoretical solutions" are not necessarily practical ones; operators would
> much rather have a choice of tools and an understanding of their tradeoffs,
> rather than an SDO diktat in terms of how to operate their networks.
>
> My 2c,
> -Woj.
>
>
>
> On 5 April 2012 22:27, jouni korhonen <[e-mail]> wrote:
>
>>
>> RADEXT is working on
>> http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-06
>> which adds attributes for RFC4191 use, for example. That is then also
>> implicitly
>> available for Diameter.
>>
>> Assuming unicast RA would be doable using just RFC6085, then there should
>> not
>> be much, if anything, to do protocol wise. The router that gets
>> provisioned per
>> host via AAA knows the l2-l3 mapping already.. and the AAA server also
>> learns
>> it. For dynamic changes of routes, AAA server can use e.g. l2 or l3
>> addresses
>> for a session identification when it sends a change of authorization..
>>
>> The assumption here is that each host gets separately authorized when
>> they attach
>> the network, which might be an issue on some links & deployments.
>> However, some
>> network architectures with multiple routers/gateways (can) already use
>> AAA for
>> centralized address management at per host granularity.
>>
>> - Jouni
>>
>>
>> On Apr 4, 2012, at 4:53 AM, Erik Kline wrote:
>>
>> >> It's true, as Jari said, that this can be accomplished in other ways,
>> and maybe it would be better if it would.   If there were some better
>> central management solution for populating unicast RA mappings on the
>> router, then unicast RA would indeed address the exact use case that I
>> think we care about.   But without the mechanism for populating routers, we
>> still have a poorly-addressed use case.   And then the question is, do we
>> want to develop a whole new protocol just to solve this one small problem?
>> >>
>> >> It might be worth developing the protocol just to put this issue to
>> bed.
>> >
>> > Is RADIUS suitable for this?  At one point it was the general
>> > non-client provisioning protocol of choice, I thought.  I have not
>> > been following any of the evolving diameter work, but would a RADIUS
>> > option suffice?
>> > _______________________________________________
>> > mif mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/mif
>>
>> _______________________________________________
>> mif mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mif
>>
>
>
> _______________________________________________
> mif mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mif
>
>