Subject: Re: [dhcwg] Address autoconfiguration

From: Ralph Droms <[email-masked]>
Date: Fri, 06 Sep 2002 11:08:27 -0400

RFC2131 specifies interface disconnect/reconnect as the trigger for a DHCP 
update.  Nothing else.

Initiating changes in routes advertised by RIP is certainly possible, 
although I don't know of any DHCP servers that will do it today.

Are you talking about DHCP/IPv4 or DHCP/IPv6?

- Ralph

At 11:11 AM 8/30/2002 +0200, Alexandru Petrescu wrote:
>Hi John,
>
>John Wells <[email-masked]> writes:
> > Hi Alex,
> > That was precisely the idea I had.  It's a good one because it gives
> > optimal routing and sidesteps communicating the home address and care-of
> > address to mobile nodes.
>
>We can discuss about this, but this is only half DHC.  It gives
>optimal routing but only within that routing domain.  No need of HoA
>and CoA but only if staying in that domain.
>
> > Can any DHCP servers do this now?
>
>I don't know of any DHCP implementation that interacts with routing
>daemons.  But enhanching a DHCPv6 implementation to send UDP messages
>to routing daemons, a proof-of-concept like, must not be very
>difficult.
>
>RIP needs some modifications to act well for this.  Again, off-topic,
>but links torn down information propagate badly.
>
>Alex
>
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Alexandru Petrescu<[email-masked]>
Date: 09 Sep 2002 00:05:29 +0200

I've mainly looked into DHCP/IPv6, there's the CONFIRM message that
has this explicit meaning to the server that the client keeps the
address after interface went down/up (presumably because of sleep
mode).  The same scenario can be designed for IPv4 too.  After quickly
skimming over RFC2131, I would suppose that the client could use a
form of DHCPINFORM to server to let it know that client keeps the same
address after client's interface has moved under another Access
Router.

The overall picture could look like this: a cloud of routers running
RIP.  One of the routers is the DHCP server and some of the other
routers are Access Routers (AR).  Each AR is also a DHCP Relay.  A
mobile host attaches its interface to one AR at a time: interface up,
interface down and up again under another AR.  Assume the mobile host
has already acquired an address from the DHCP server.  When the mobile
is changing its attachment, all it has to do is to CONFIRM its address
to the DHCP server through the AR.  When the relay on the AR receives
the CONFIRM it normally forwards it to the server and, in addition,
broadcasts a RIP Update containing its normal routing table plus an
entry corresponding to the address allocated to the host (this is
found in the CONFIRM).  When the DHCP server generates the DHCPACK for
this CONFIRM it also generates a RIP Update containing the route
towards the new AR, and removing the route through the old AR.  The
route towards the Mobile address through the old AR should disappear
and the route through new AR should appear, within all the routing
cloud.

What do you think?

Alex

Ralph Droms <[email-masked]> writes:
> RFC2131 specifies interface disconnect/reconnect as the trigger for a
> DHCP update.  Nothing else.
>