Re: [dhcwg] Address autoconfiguration and route updates for mobility

Alexandru Petrescu<petrescu@crm.mot.com> Mon, 09 September 2002 14:55 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04891 for <dhcwg-archive@odin.ietf.org>; Mon, 9 Sep 2002 10:55:57 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g89Ev4J05397 for dhcwg-archive@odin.ietf.org; Mon, 9 Sep 2002 10:57:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g89Ev4v05394 for <dhcwg-web-archive@optimus.ietf.org>; Mon, 9 Sep 2002 10:57:04 -0400
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04857 for <dhcwg-web-archive@ietf.org>; Mon, 9 Sep 2002 10:55:27 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g89ErPv04857; Mon, 9 Sep 2002 10:53:32 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g89EQjv02225 for <dhcwg@optimus.ietf.org>; Mon, 9 Sep 2002 10:26:45 -0400
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25824 for <dhcwg@ietf.org>; Mon, 9 Sep 2002 02:57:37 -0400 (EDT)
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id XAA21926; Sun, 8 Sep 2002 23:59:09 -0700 (MST)]
Received: [from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id XAA27574; Sun, 8 Sep 2002 23:59:00 -0700 (MST)]
Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr01.mot.com (8.11.6/8.11.6) with ESMTP id g896wtT02244; Mon, 9 Sep 2002 01:58:56 -0500
Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 39ED12EC86; Mon, 9 Sep 2002 09:00:06 +0200 (CEST)
To: Ralph Droms <rdroms@cisco.com>
Cc: John Wells <wells@ieee.org>, dhcwg@ietf.org
Subject: Re: [dhcwg] Address autoconfiguration and route updates for mobility
References: <20020829180950.B8009@io.irean.vt.edu> <20020829112549.A5758@io.irean.vt.edu> <m3n0r563l0.fsf@test9.crm.mot.com> <20020829180950.B8009@io.irean.vt.edu> <4.3.2.7.2.20020906110604.02209010@funnel.cisco.com>
From: Alexandru Petrescu <petrescu@crm.mot.com>
Date: Mon, 09 Sep 2002 00:05:29 +0200
In-Reply-To: <4.3.2.7.2.20020906110604.02209010@funnel.cisco.com>
Message-ID: <m33csk87di.fsf_-_@test9.crm.mot.com>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Lines: 76
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>

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 <rdroms@cisco.com> writes:
> 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 <wells@ieee.org> 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
> >dhcwg@ietf.org
> >https://www1.ietf.org/mailman/listinfo/dhcwg
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg