DHCP in unrecommended IP block
parahumanoid
Sorry if this is not the most appropriate place for this post, but I
found no other.
Having examined the ipv4 link local RFC and the dhcp RFC, I found that
using the reserved 169.254/16 IP block for DHCP address alocation is
not prohibited, but rather unrecommended (thank God). That makes me
expect a compliant dhcp server to allow administrator do so at his own
risk. I am using MS Win2003 DHCP server. My attempt to set the scope
for range 169.254.0.10 - 169.254.0.127 / 255.255.0.0 has failed with a
message about an invalid range assignment. Does anyone know of a way
to fight this back?
Thank you for your help.
Alex.
Gerard Bok
<parahu...@excite.com> wrote:
>Having examined the ipv4 link local RFC and the dhcp RFC, I found that
>using the reserved 169.254/16 IP block for DHCP address alocation is
>not prohibited, but rather unrecommended (thank God). That makes me
>expect a compliant dhcp server to allow administrator do so at his own
>risk. I am using MS Win2003 DHCP server. My attempt to set the scope
>for range 169.254.0.10 - 169.254.0.127 / 255.255.0.0 has failed with a
>message about an invalid range assignment. Does anyone know of a way
>to fight this back?
Imho you shouldn't fight it at all :-)
Basic to DHCP is that (only) the server assigns IP-numbers.
The range you want to use is APIPA. So, any host can claim any
IP-address within that range without any server support.
That's not IP assignment, it's called 'disaster creation' :-)
--
Kind regards,
Gerard Bok
parahumanoid
Since it receives one, it shouldn't proceed to the apipa procedure.
The auto-assignment scenario goes into action if there is no dhcp
available. I must be missing something, since I don't see anything as
drastic as "disaster" in this. I already gave up the idea because of
the routing issue (absence thereof, to be exact), but I would like to
entertain this idea to the end if you mind supporting this
conversation. Correct me if I am wrong, but isn't the following the
case:
DHCP server up (serving 169.254/16 range) - server ip is 169.254.0.1
client A comes online and broadcasts IP request. DHCP replies with an
offer. Client accepts (169.254.12.2)
client B comes online and broadcasts IP request. DHCP replies with an
offer. Client accepts (169.254.13.1)
DHCP server goes down
client C comes online and broadcasts IP request. No reply. It take
initiative to pick an IP address from the 169.254/16 range and test if
there's someone there (169.254.13.1). There is. It generates another
one (169.254.13.7) and tests it. It's free. Address is self-
assigned.
So, where's the disaster, if IP reservation is not a requirement? The
only bad thing I see is if someone would take up the 169.254.0.1
address while in APIPA mode. That would be a problem when the DHCP
comes on, but the chances and frequency of this problem in a 20-PC
network are kind of slim. I just want you to get me clear on any
theoretical nuance I may be missing.
Thank you for your answer.
parahumanoid
James Carlson
They're doing the right thing -- saving you from yourself.
If you need a private IP address range, pick one from the RFC 1918
lists. In short:
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
--
James Carlson, Solaris Networking <james.d...@sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
Barry Margolin
parahumanoid <parahu...@excite.com> wrote:
> So, where's the disaster, if IP reservation is not a requirement? The
> only bad thing I see is if someone would take up the 169.254.0.1
> address while in APIPA mode. That would be a problem when the DHCP
> comes on, but the chances and frequency of this problem in a 20-PC
> network are kind of slim. I just want you to get me clear on any
> theoretical nuance I may be missing.
Even that shouldn't be a disaster. Before accepting an assignment from
the DHCP server, the client is supposed to perform an ARP query to see
if the address is already in use. Similarly, in APIPA mode the machine
has to send an ARP query to see if the address it's thinking about
self-assigning is in use.
So there usually shouldn't be a conflict even if machines are
self-assigning addresses in the same range as the DHCP server. The only
case where this will happen is if the network is segregated at the time
that a conflicting address is assigned, so the ARP check fails.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Vernon Schryver
Barry Margolin <bar...@alum.mit.edu> wrote:
>Even that shouldn't be a disaster. Before accepting an assignment from
>the DHCP server, the client is supposed to perform an ARP query to see
>if the address is already in use. Similarly, in APIPA mode the machine
>has to send an ARP query to see if the address it's thinking about
>self-assigning is in use.
>
>So there usually shouldn't be a conflict even if machines are
>self-assigning addresses in the same range as the DHCP server. The only
>case where this will happen is if the network is segregated at the time
>that a conflicting address is assigned, so the ARP check fails.
There are many ways to "segregate" (or more commonly "partition") a
network besides disconnecting cables. Anything that can make that ARP
check fail including congestion, high packet loss rates (e.g. due to
violations of CSMA/CD delay/cable limits), and link-layer filters on
broadcasts can allow conflicting address self-assignments.
For a fun example, consider the effects limits on "ARP screaming" in
the face of conflicts. Reasonable (by my lights) ARP implementations
rate-limit their ARP output. If two or more hosts have been assigned
a single IP address and have been fighting over it with repeated ARP
packets, a newcomer might announce its own prospective claim and not
be contradicted by the other claimants.
In other words, many of us disagree with The Wizards of Redmond and
think there are there are good and sufficient reasons to put up with
the complications and hassles of DHCP leases and so forth instead of
merely using IPv4 ARP to assign addresses.
Vernon Schryver v...@rhyolite.com
James Carlson
> In other words, many of us disagree with The Wizards of Redmond and
> think there are there are good and sufficient reasons to put up with
> the complications and hassles of DHCP leases and so forth instead of
> merely using IPv4 ARP to assign addresses.
I completely agree. LLA is extremely problematic -- especially for
those systems with two or more interfaces, where it's just a crime
scene.
Getting back to the original point, though, I think the user is well
advised to avoid having his DHCP server hand out leases within the
range reserved for LLA. It's utterly pointless, as there are better
ranges to use for this, and ought to result in addresses slowly
crudding up (being falsely marked as "unusable") in the server's
database over time.
robert...@yahoo.com
> In other words, many of us disagree with The Wizards of Redmond and
> think there are there are good and sufficient reasons to put up with
> the complications and hassles of DHCP leases and so forth instead of
> merely using IPv4 ARP to assign addresses.
Of course MS doesn't actually recommend APIPA for anything other than
trivial networks. And it's a reasonable solution for someone with a
handful of PCs they want to hang together. It's quite handy for
upgrades to - just plug in a crossover cable between the old and new
machine, and away you go.
And if you do have a DHCP server (as you would, for example, if you
have a SOHO router attaching you to the Internet), Windows will use
that first - APIPA is the fallback.
Anyway, from MS:
"Automatic configuration
TCP/IP uses Automatic Private IP Addressing (APIPA) by default to
provide automatic configuration, using the IP address range
169.254.0.1 to 169.254.255.254 and the subnet mask 255.255.0.0. There
is no automatic configuration of a default gateway, DNS server, or
WINS server since APIPA is designed for networks that consist of a
single network segment and that are not connected to the Internet."
Note the last sentence: "...APIPA is designed for networks that
consist of a single network segment and that are not connected to the
Internet."