Re: [mif] Route option for DHCPv6

I asked this on the jabber, but it should probably go the mail list as
well... 
Why is this not RFC 3442bis?  DHCP option 121 already does this function for
IPv4, so this is really just creating the IPv6 version of the existing
option. It is required for VPN split tunnel, so the entire question about
doing it or not is moot. People use 121 / 249 (MSFT private version that
instigated 3442), so they need the IPv6 version of that. 

Tony

-----Original Message-----
From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Ted
Lemon
Sent: Thursday, March 29, 2012 6:52 AM
To: Margaret Wasserman; Alexandru Petrescu
Cc: mif@ietf.org
Subject: Re: [mif] Route option for DHCPv6 - next steps?

> The DHCPv6 route option is _not_ a dynamic routing protocol.  [etc]

Wow, thanks, that's a really good point.   It would be a big improvement to
this protocol if in fact we operated that way.

However, there is one issue to consider: what happens when a route is
removed from the configuration of the DHCP server after it's been installed
by a client, and a new route replaces it?   We'd like that route to expire.
So even though I think you are right that we should *consider* these routes
to be essentially statiic, I think we still need to put lifetimes on them on
the client side, when the client installs the route.   This lifetime should
be long enough that we can count on the routing table entry being refreshed
by a DHCP renewal or DHCP information refresh before the entry expires, but
short enough that if a route is removed from the DHCP server configuration,
it does not remain, stale, in the client's routing table for an inconvenient
time.
_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif