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

[Wojciech Dec <[e-mail]>]

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
>