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

["Tony Hain" <[e-mail]>]

Margret,

 

I am a strong believer we need to do both. This continuing crap that we need
to isolate useful tools and only have one version which can't ever solve all
problems has to end. There will be networks that use DHCP (even as a trust
anchor, as absurd as that concept is), and there will be networks that want
to operate without DHCP. There should be a mechanism for each of those
operational models. 

 

Stop trying to use the standards process to drive people to your favorite
mode, and simply make sure there is a way to do the job that fits your
situation. For those that say the end systems won't want to do both, that is
both true and false. For end systems that live almost exclusively in one
operational model, those vendors will not want to bother with the other, but
for the vendors the realize that their system might be in either, doing both
is not that big a deal. The hard issue is deciding priority if you hear
both, and personally I prefer that the end user gets to choose because
network operators always think they know best, when in fact they almost
never do.

 

Tony

 

 

 

From: Margaret Wasserman [mailto:[e-mail]] 
Sent: Friday, March 30, 2012 12:22 AM
To: Ted Lemon
Cc: Tony Hain; [e-mail]
Subject: Re: [mif] Route option for DHCPv6 - next steps?

 

 

Hi Ted,

 

On Mar 29, 2012, at 11:37 PM, Ted Lemon wrote:


Tony, if you really think this option is a good idea, can you send me some
email explaining why you think it is, privately, since the working group is
at least temporarily not working on this?   I'd like to get some clarity on
the reasons why people want this that can be used next time it comes up, so
that we have a clear set of use cases to present next time.  The VPN split
tunnel case isn't familiar to me.

 

Actually, this topic is still in the MIF charter, and there was pretty
strong consensus that we still want to work on a solution to this problem.

 

What there wasn't consensus on, unfortunately, is whether we should specify
a DHCPv6 option to solve it -- ~12 people thought we should, and ~18 people
thought we should consider something else (unspecified).  Sadly, those 18
people probably won't unite around a single alternative, so what we have is
a bit of a mess...

 

I think it would make sense to document a couple of solid use cases where we
think that something like this is needed, and current RAs can't or don't
solve the problem.  

 

Tony, it sounds like you have a specific VPN use-case in mind, could you
elaborate?

 

As I understand it, there is a need to get routes to cell phones that tell
them that certain services (ones that are only accessible over 3GPP) need to
be routed via the 3GPP interface, not via the 802.11 interface, even if
802.11 is cheaper, faster and preferred for general traffic.  I am wondering
if this is essentially the same as the VPN use case?  Is there a reason why
routes could not be transmitted over ND for this purpose, though?

 

One alternative that was raised at the mic, but that has not (to my
knowledge actually been proposed anywhere) was the use of unicast ND for
cases when you want to configure different routes on different nodes.  Are
there problems in this space that would not be solved by doing that?  If so,
what are they?  If not, perhaps we need to write up a unicast ND mechanism?

 

Margaret