Path: ...!npeer.as286.net!npeer-ng0.as286.net!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Marco Moock <mm+usenet-es@dorfdsl.de>
Newsgroups: comp.os.linux.misc
Subject: Re: I never thought of this scenario
Date: Sat, 20 Apr 2024 22:33:14 +0200
Organization: A noiseless patient Spider
Lines: 49
Message-ID: <v018qb$3rkif$1@dont-email.me>
References: <uv2g3g$39k$1@tncsrv09.home.tnetconsulting.net>
	<uvcmop$75v$1@tncsrv09.home.tnetconsulting.net>
	<uvcu5a$2qdb0$5@dont-email.me>
	<uvd6m3$n3m$1@tncsrv09.home.tnetconsulting.net>
	<uvhtft$3th0n$6@dont-email.me>
	<uvhv0m$kq3$1@tncsrv09.home.tnetconsulting.net>
	<uvs61u$2g9b9$5@dont-email.me>
	<uvsv4f$3cvv$1@news1.tnib.de>
	<uvv1qf$392q8$2@dont-email.me>
	<uvve26$3f4ea$1@dont-email.me>
	<wwvh6fwxy7q.fsf@LkoBDZeT.terraraq.uk>
	<v0108c$3q01h$1@dont-email.me>
	<v0111s$3q1fd$1@dont-email.me>
	<v013pv$3qmkf$1@dont-email.me>
	<v017kv$td0$3@tncsrv09.home.tnetconsulting.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 20 Apr 2024 22:33:15 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="89470782f4cf1cd6ffc59467c91451f2";
	logging-data="4051535"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+uNhdIawKN4rLocp07YatM"
Cancel-Lock: sha1:WERJ6tQspbcE2Z0TbxySRwGAEL8=
Bytes: 3518

On 20.04.2024 um 15:13 Uhr Grant Taylor wrote:

> On 4/20/24 14:07, Rich wrote:
> > Yes, correct.  However, that is not "DHCP" the protocol itself 
> > specifying such.  That is the IP layer specifying that certian 
> > addresses used in UDP packets are not routed.  
> 
> Nit-pick:  That's the IP layer saying that certain addresses can't be 
> routed.  It doesn't matter what transport is on top of those IP
> packets.
> 
> > The reason it impacts DHCP is that the "bootstrap an IP address 
> > configuration" portion of DHCP means that those addresses are all 
> > the client can make use of until after it has been configured with 
> > a valid IP address for the local subnet.  
> 
> Nit-pick:  I believe I've read about DHCP implementations that
> remember what they used last time and will start to use them instead
> of 0.0.0.0. If that remembered IP fails / is rejected for some reason
> then it falls back to a discover.
> 
> RFC 951 - Bootstrap Protocol - the precursor to DHCP - section 3 
> paragraph 2 says:  "In the IP header of a bootrequest, the client
> fills in its own IP source address if known, otherwise zero.  When
> the server address is unknown, the IP destination address will be the
> 'broadcast address' 255.255.255.255."
> 
> So I'm not sure that a client /must/ use 0.0.0.0 -> 255.255.255.255
> when doing a BOOTP / DHCP request.

How can a DHCP client assume that a remembered address can be still
used?
If the lease is still valid, it can use it and contact the server via
unicast, if there is no valid lease, it must not use the IP anymore
because it could be assigned to some other node.

IIRC IP unicast src addr can only be used if the lease is still valid
and the client wants to extend the lease.
Of course asking the DHCP for additional information after the IP has
been assigned is another situation where unicast can be used.

Does anybody know other situations?

-- 
kind regards
Marco

Send spam to 1713618799muell@cartoonies.org