[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: dhcp/modecfg summary


> > - the dhcp model provides a great deal of flexibility due 
> to richness of
> > options; you have to look at how dhcp is being used in contemporary
> > networks to understand this. Clearly, some folks have yet 
> to do this. As
> > for
> > extensibility, vendor-specific options provide a clear path.
> You're now putting some of your vendor-specific VPN policy on 
> your dhcp
> server.  VPN policy long-term belongs in the IPSP (if that 
> ever ends up
> being deployed).  In the short term though, I definitely feel 
> better using
> mode-cfg, and having the policy stored in the VPN head-end (or RADIUS
> server, or LDAP), than in a DHCP server.

Stephane, I think this is well-put.  We're used to using Radius/LDAP for
policy - not so used to using DHCP.

<snip again>

> What you fail to realize is that there are 2 reasons why 
> vendors have chosen
> to use mode-cfg in the past, and are reluctant to part with it.
> 1 - Ease of implementation  (yeah, yeah, dhcp not rocket 
> science, yada yada
> yada...).  At my last count, which was quite a while 
> ago...(bakeoff in San
> Diego, 2000?) there were something like 25 different 
> implementations of
> mode-cfg w/IKEv1 by about 20 different vendors.  Why mode-cfg 
> and not DHCP?
> Use a small hammer for a small nail....
> 2 - Extensibility
> This is the stuff you don't know about, because it's not 
> public.  There's
> more to bootstrapping a VPN RA Client than IP, WINS, DNS.  
> There's "value
> add" stuff you can do too.  This is a little taboo because 
> *some* of it
> overlaps with IPSP.  When IPSP is done and deployed, we might 
> pull some
> stuff out of our mode-cfg extensions and use IPSP.  But we'll 
> never be able
> to do it all in IPSP, because some of it is crazy customer 
> features (which
> will never be standardized...) and some of it is very implementation
> dependant.  The point here is that though you'd like to 
> believe we're just
> lazy and don't want to spend a couple of days hooking into 
> the various DHCP
> implementations in the various stacks and OSs that we need to 
> deal with (OK,
> I'd rather not to tell you the honest truth :), we just plain can't
> completely switch to *just* DHCP, because it can't do 
> everyting we need it
> to do.
> So, we're not just pig-headed.  We have real customer needs that we've
> solved with mode-cfg, and we can't drop those features in the 
> upgrade to
> IKEv2.

Again, I think this is well-stated.  We have experience with mode config
- we've seen it solve problems we have.


> Stephane.
> >
> >
> > Scott