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

[Arifumi Matsumoto <[e-mail]>]

Hi,

Besides multi-interface cases, DHCP relay functionality is widely deployed and really helpful function to implement a new way of information distribution.

Replacing or upgrading all the provider edge routers should be real headaches to access network providers, because the amount of edge routers tend to be large, and they are more and more overloaded with various features, and so not cheap. The provider edge routers are the place where control plane and data plane reside together. And DHCP servers and RADIUS servers are those entities separated from the data plane, so they are relatively cheaper and easier to get upgraded.

From the access network provider perspective,
RADIUS based approach needs standardization, implementation at the routing equipments, and upgrade of RADIUS servers.
DHCP based approach needs upgrade of just the DHCP servers.

How can we say this is not the show stopper ?

Best regards,

On 2012/04/11, at 21:10, Tao Sun wrote:

> 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
> 
> 
> _______________________________________________
> mif mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mif


--
Arifumi Matsumoto
  NGN System Architecture Project
  NTT Service Integration Laboratories
  E-mail: [e-mail]
  TEL [phone] FAX [phone]