"Verizon managed" devices / IP address range

[Observer1]

I had intended to use 100-199 for my static addresses, and <100 for dynamic, but am unable to assign static addresses in the block 192.168.1.100-192.168.1.150.  The error message is "IP Address is reserved for Verizon Managed Device."  

I assumed it was because I had configured my DHCP IPv4 address distribution range as 192.168.1.2-192.168.1.99, but when I changed the distribution range to 192.168.1.2-192.168.1.109 (even rebooting the G3100), the reserved block appears to remain 192.168.1.100-192.168.1.150.

Did I miss the documentation that this block is special?  At first I thought it might be related to Guest or IoT devices, but the former are assigned in 192.168.200.x, and the latter are assigned from the Primary "network" pool.

[Cang_Household]

You should configure static IP addresses on the devices themselves. You cannot config static IP addresses for devices on the G3100.

Or, do you mean Static DHCP reservation? You cannot config a static DHCP lease on the G3100 if that address is not managed by G3100's DHCP server.

[Observer1]

I meant static DHCP reservation.

And you can give devices static reservations outside the dynamic range defined for DHCP dynamic assignment.  As I noted in my original post, I was able to assign static addresses outside of the dynamic range 2-99, but only above .150.

I should also have been clearer that when I defined the dynamic range to be 2-109, I still could not statically assign 100-109 (because 100-150 are apparently reserved for "Verizon managed devices").

[Cang_Household]

---

@Observer wrote:

And you can give devices static reservations outside the dynamic range defined for DHCP dynamic assignment.  As I noted in my original post, I was able to assign static addresses outside of the dynamic range 2-99, but only above .150.

---

Even if you can, that would not make any sense. Reserving a static DHCP address outside the DHCP address pool would be analogous to walk up to a hotel front desk and asks to reserve a room not owned by the hotel.

[Observer1]

I understand your hotel room analogy, but didn't realize there was such a constraint in the DHCP specification (RFC 2131?).  

Surely it is the admin's prerogative to configure one or more DHCP servers to reliably and conveniently serve her address allocation needs?  If her address space plan includes blocks in which she does not want any dynamically-assigned devices, but would still like DHCP to automate device configuration (rather than manually configure the static address in each of those "static" devices), shouldn't she have the option to do so with a single DHCP server?

You are implying that such a configuration is impermissible, and that she should instead employ at least two DHCP servers, one to handle the dynamic assignments, and another to handle the static assignments.

[Cang_Household]

Nothing in the RFC you cited prohibits the presence of two or more DHCP servers on the link; however, I doubt SOHO devices are smart enough to deal with multiple DHCP responses, though required by the RFC.

The RFC you cited also demand DHCP  mechanism should coexist with static addresses and DHCP servers should not assign an already allocated address, whether by the admin statically or by previous DHCP transactions. The above amounts to DHCP server should be aware of all static addresses in use, even if the addresses are not assigned through the DHCP server.

Then you only need to leave your DHCP pool as 192.168.1.1-254, since the DHCP server is aware of all current addresses in use and whether they are static or dynamic. I can at least confirm G1100 and G3100’s DHCP server operates in this way.

[Observer1]

---

@Cang_Household wrote:

Nothing in the RFC you cited prohibits the presence of two or more DHCP servers on the link... The RFC you cited also demand DHCP mechanism should coexist with static addresses and DHCP servers should not assign an already allocated address...

---

Right.  But I hope you will now agree that it is permissible to configure one's DHCP server to allocate static IP addresses outside of the dynamic range configured in that DHCP server.  In fact, there is no reason a sophisticate DHCP server couldn't support multiple dynamic ranges, and then select the pool from which to allocate by device type.  And then hand out static addresses as well (whether in the pools or not).

---

...Then you only need to leave your DHCP pool as 192.168.1.1-254, since the DHCP server is aware of all current addresses in use and whether they are static or dynamic. I can at least confirm G1100 and G3100’s DHCP server operates in this way.

---

I plan my address space.  In the same way that Verizon has its reasons for apparently reserving 100-150 for STBs, I reserve certain space for certain devices.  I don't want DHCP to dynamic allocate addresses in my reserved space for other devices.  You suggestion to configure my DHCP pool as 1-254 (I think you meant 2-254) fails to meet my requirements.  Configuring my DHCP pool as 2-99, and then defining static addresses above 150 meets my requirements.  (There doesn't appear to be anything wrong with that approach, although it requires some imagination.)

[Cang_Household]

---

@Observer wrote:
But I hope you will now agree that it is permissible to configure one's DHCP server to allocate static IP addresses outside of the dynamic range configured in that DHCP server. 

---

---

DHCP server does not allocate static IP addresses. When we say static IP addresses, we mean the intrinsic IP address of a device that is explicitly defined on the device itself. Static DHCP reservation only ensures the DHCP server to hand out the same dynamic IP every time when requested. Although you can argue that IP address is a de facto static IP address, the assignment falters when we turn off the DHCP server.

Again, although what you proposed is operationally feasible, it may be an overstepping of authority on the DHCP server's part. DHCP server should manage only the addresses defined in its address pool. Giving leases other than belonging to the address pool is an overstepping of network administrative authority.

[Observer1]

---

@Cang_Household wrote:

---

@Observer wrote:
But I hope you will now agree that it is permissible to configure one's DHCP server to allocate static IP addresses outside of the dynamic range configured in that DHCP server. 

---

---

DHCP server does not allocate static IP addresses. When we say static IP addresses, we mean the intrinsic IP address of a device that is explicitly defined on the device itself. Static DHCP reservation only ensures the DHCP server to hand out the same dynamic IP every time when requested. Although you can argue that IP address is a de facto static IP address, the assignment falters when we turn off the DHCP server.

Again, although what you proposed is operationally feasible, it may be an overstepping of authority on the DHCP server's part. DHCP server should manage only the addresses defined in its address pool. Giving leases other than belonging to the address pool is an overstepping of network administrative authority.

---

You have failed to cite any authority, yet claim something "is an overstepping of network administrative authority". 

Also, you seem to falsely assume:

• that the specification describing how network entities should operate via the DHCP protocol also constrains how a DHCP server may operate internally.
• that an IP address is intrinsically static or dynamic, instead of simply acknowledging that it is merely an address used for routing packets.  How an address is assigned to a device is either automatic (supplied via some network protocol) or manual (input at the device by the operator).
• that a failure mode (e.g., among DHCP servers) defines what is permitted in terms of DHCP server configuration.  Perhaps you meant to say that one should keep in mind failure modes while designing networks.  That would be a safe recommendation.  But to leap from that safe position to a statement of the form "you can't do that because..." without being able to cite an authority is unsupported.

I would be more interested in reading your theories if you could back them up with references. 

[Cang_Household]

Let's keep the discussion civil and I will cite lines from RFC's going forward.

About "overstepping network administrative authority," I was trying to be comical, I guess the text does not convey tones. Can you refute my hotel reservation analogy? I am interested to hear that.

I will address all of the alleged assumptions at a later time.

[Observer1]

---

@Cang_Household wrote:

Let's keep the discussion civil and I will cite lines from RFC's going forward.

About "overstepping network administrative authority," I was trying to be comical, I guess the text does not convey tones. Can you refute my hotel reservation analogy? I am interested to hear that.

I will address all of the alleged assumptions at a later time.

---

I have kept the discussion civil, and appreciate that you have too; my complaints have to do with going down rabbit holes without specifications to enlighten the way.

I appreciate the attempt at humor, but it didn't seem you were joking about "overstepping authority".  That assertion was consistent with other claims of yours, very few of which, if any, have been shown to be supported by facts.

I refuted the hotel reservation analogy a few times, but perhaps I was too inferential.  E.g., you claimed that an individual DHCP server, once configured to hand out dynamic addresses from a given range, is constrained [by no specification citations thus far] to only respond within that universe of IP addresses.

This improper constraint relies on an assumption that the internal "pool definition" of that DHCP server might be shared with another entities in the network.  I am not aware of that possibility (and it would presumably have to be in the DHCP spec).  Instead, it is simpler to assume it is merely up to the DHCP admins to configure their servers to operate in compatible fashion with one another, and for DHCP server programmers to merely comply with the DHCP spec, and do whatever they wish w.r.t. their internal configuration and operation methods.

Also, IP addresses are IP addresses.  They are not owned by a DHCP server.  As you have pointed out, an admin can manually configure an IP address (into a device) on a subnet that conflicts with the DHCP server's  configured (not owned) dynamic IP range.  The DHCP server is supposed to notice and not hand out that conflicted address despite it being in the range that DHCP server considers to be fair game for dynamic allocations.  Doesn't this effectively mean that server's dynamic range is now bifurcated into two ranges:  one below the conflicting address, and another beginning above it?  And if there are many conflicts, that poor DHCP server could have end up with a sparse list, not a "range".

I mention these not as concrete statements that the configuration I described is valid.  But absent a statement in a specification that it is not valid, it probably is.  And I shared logic to help you get comfortable with that thinking, which would seem outside the box if you began with the assumption that the dynamic range specified for a DHCP server was, in fact, THE RANGE allowed for that server.

I'm guessing the reason that FIOS routers have allowed me to do this for the past 15 years is because we're all allowed to do this.  And it just doesn't seem worth spending more time on this "Solved" thread.

[Cang_Household]

---

@Observer wrote:
you claimed that an individual DHCP server, once configured to hand out dynamic addresses from a given range, is constrained [by no specification citations thus far] to only respond within that universe of IP addresses.

---

---

Section 4.3.1 of RFC2131 is appropriate for investigating the above claim/opinion.

4.3.1 DHCPDISCOVER message

   When a server receives a DHCPDISCOVER message from a client, the
   server chooses a network address for the requesting client.  If no
   address is available, the server may choose to report the problem to
   the system administrator. If an address is available, the new address
   SHOULD be chosen as follows:

      o The client's current address as recorded in the client's current
        binding, ELSE

      o The client's previous address as recorded in the client's (now
        expired or released) binding, if that address is in the server's
        pool of available addresses and not already allocated, ELSE

      o The address requested in the 'Requested IP Address' option, if that
        address is valid and not already allocated, ELSE

      o A new address allocated from the server's pool of available
        addresses; the address is selected based on the subnet from which
        the message was received (if 'giaddr' is 0) or on the address of
        the relay agent that forwarded the message ('giaddr' when not 0).

Assuming a new device joins the network, knows nothing about the network, and does not demand to obtain a particular IP address lease, the DHCP server on link would choose an address satisfying the 4th bullet cited above?

I interpret the "pool of available addresses" contains a limited and constrained number of addresses set by a network admin.

---

@Observer wrote:
 Doesn't this effectively mean that server's dynamic range is now bifurcated into two ranges:  one below the conflicting address, and another beginning above it?  And if there are many conflicts, that poor DHCP server could have end up with a sparse list, not a "range".

The numerical range set by the admin is not an absolute range from which the DHCP server should assign address. DHCP server should probe a selected address before assigning it. RFC2131 Section 3.1.2

When allocating a new address, servers SHOULD check that the offered network address is not
      already in use; e.g., the server may probe the offered address
      with an ICMP Echo Request. 

Whether the final addresses assigned by the DHCP server constitutes a single continuous range or not does not alter the nominal range designation set by the admin, also known as the "pool."

If the DHCP server should check the address before assigning it, it opens up the possibility for multiple DHCP servers on the same link to be configured with overlapping address pool ranges.

Please rebut any misinterpreted/erroneous/incomplete points.

[Observer1]

o A new address allocated from the server's pool of available addresses; the address is selected based on the subnet from which the message was received (if 'giaddr' is 0) or on the address of the relay agent that forwarded the message ('giaddr' when not 0).

Assuming a new device joins the network, knows nothing about the network, and does not demand to obtain a particular IP address lease, the DHCP server on link would choose an address satisfying the 4th bullet cited above?

I interpret the "pool of available addresses" contains a limited and constrained number of addresses set by a network admin.

You interpretation appears to stem from your assumption that the DHCP specification imposes constraints on the internal organization/operation of a DHCP server, rather than how entities engaged in the DHCP dance must interact with one another.  As an example that responses aren't constrained by the mythical "pool", the third bullet states that the DHCP server may respond with the requested address, with no reference to such address falling within the "pool of available addresses".

Unless the specification explicitly defines the "the server's pool of available addresses", the reference is merely conceptual, and the definition is left up to the programmer.  E.g., if someone wanted to write a DHCP server with a pool reserved for each type of device class making DHCP requests, then that server would be responding from within one of its many defined pools of available addresses.  Obviously, that server's UI would have to allow multiple ranges to be specified.  But from the point of view of the rest of the universe, that server would be compliant with the spec because the address would be allocated from within the abstract notion of the "server's pool of available addresses" (however that server chose to define them).  I'll return to this example later.

In other words, how the server defines its "pool" is irrelevant in the broader "system" context.  It's too bad you didn't reference the paragraph in the specification soon after your quote (emphasis added):

   ...Note that, in some network architectures (e.g., internets with more
   than one IP subnet assigned to a physical network segment), it may be
   the case that the DHCP client should be assigned an address from a
   different subnet than the address recorded in 'giaddr'.  Thus, DHCP
   does not require that the client be assigned as address from the
   subnet in 'giaddr'.  A server is free to choose some other subnet,
   and it is beyond the scope of the DHCP specification to describe ways
   in which the assigned IP address might be chosen.

All along I have simply said that I was unaware of a DHCP specification requiring the address returned by a DHCP to come from within its defined "dynamic pool".

Of course, the programmer of a given DHCP server may choose to impose such a constraint.  That programmer should then document the constraint, e.g., "static addresses must be assigned within the defined dynamic address range", and the program should reject attempts by an admin to configure a static address outside the dynamic range.  And should similarly add a test to reject attempts to redefine the dynamic range if any previously defined static addresses would now fall outside said range.

Since the DHCP server code in the Verizon routers has not rejected my arbitrary static definitions over the past 15 years, and I haven't seen any documentation to support your claimed constraint, I don't believe it is impermissible to define static addresses outside of the defined dynamic range.  Even if Verizon did change its DHCP server policy and introduce such a constraint, then it would only apply to subsequently-deployed Verizon DHCP servers.

Remember my example earlier about programming a DHCP server to respond to certain requests based on device type?  Doesn't the Verizon DHCP server allocate from within its secret pool of xx.xx.100-150 when responding to STBs making DHCP requests?  According to your theory, that should not be allowed if the dynamic range can be configured with the upper limit of .99.

Finally, I refer you to the IPv4 Address Distribution web configuration page on the G3100.  You will see that the defined pool is labeled the "Dynamic IP Range".  It does not call it the "pool of available addresses".  In fact, one might reasonable argue that admins should NOT put static addresses inside a "Dynamic IP Range".  

(I'll end this reply with another reminder:  I marked this thread "Solved" at least a dozen responses ago when someone answered my question and explained that the mystery "Verizon managed devices" are STBs, and that addresses 100-150 are reserved for them, regardless of whether FIOS TV service has been provisioned or not.)

[Cang_Household]

After making an extended review of our conversation, although I still do not agree with all of your inferences made in connection to RFC 2131, I now agree with your direct interpretation of the RFC 2131.

I would not reply further on this thread, as you suggested that the solution has already been marked.

[LawrenceC]

Just a reminder to everyone to please keep your posts courteous and respectful of others.  Thanks.

[Edg1 · Accepted solution]

---

@Observer wrote:

I had intended to use 100-199 for my static addresses, and <100 for dynamic, but am unable to assign static addresses in the block 192.168.1.100-192.168.1.150.  The error message is "IP Address is reserved for Verizon Managed Device."  

---

That block is reserved for set-top boxes if you have tv service. 

[Observer1]

Ah, that makes sense.  

I don't have FIOS TV service (just 3 digital phone lines), so perhaps that block is unconditionally reserved.  

Interesting that Verizon reserves ~20% of the primary subnet address space for set-top boxes, and doesn't warn that a dynamic DHCP block of ~150 addresses (2-150) only contains room for ~100 of your devices.

[Cang_Household]

---

@Observer wrote:

...so perhaps that block is unconditionally reserved.  

---

I think you are still confusing Static DHCP reservation with Static IP assignment.

Normally, if you would like to assign a static IP to the device, you would configure it directly on the device. You don't need a DHCP server for your network to work. A router does not need to assign IP addresses in order to be called a router.

The device won't disallow the assignment of 192.168.1.100-150, and the G3100 will realize those addresses are occupied and won't assign STBs these addresses if you happen to have STBs. Static DHCP reservation should only be used when the device can only be configured with DHCP.

[Observer1]

I don't think I have been or am still confused about the two addressing concepts.  While one can certainly configure addresses manually in devices, DHCP can also be used to assign specific addresses to devices via the DHCP protocol.  Whether simply applying a preference to re-assign an address previously used by a device, or by handing out a static address the admin explicitly wishes to have DHCP hand out for the device.

Could you provide an authoritative source for your assertion:  "Static DHCP reservation should only be used when the device can only be configured with DHCP."

FYI, my G3100 DHCP refuses to allow the addresses 100-150 to be defined as static, even though I have no STBs in my system and never have since installing the G3100 (FIOS/phone-only installation).  This leads me to conclude that the block is unconditionally reserved.

[Cang_Household]

---

@Observer wrote:

Could you provide an authoritative source for your assertion:  "Static DHCP reservation should only be used when the device can only be configured with DHCP."

I don’t believe there is a standard on DHCP reservation. I would avoid using non-standardized features because different devices may disagree on how to implement it. Also, as another CL mentioned, if your DHCP server goes down or compromised, all DHCP devices would go down with it.

[Observer1]

---

I don’t believe there is a standard on DHCP reservation. I would avoid using non-standardized features...

---

That combination of statements is illogical.

---

...because different devices may disagree on how to implement it.

The topic we have been discussing is limited to the internal workings of a single DHCP server.  No disagreement on the network could result.  Or are you suggesting that DHCP servers share their configuration details with other DHCP servers (I hand out 2-99, or 2-254)?  If so, could you point me to that part of the RFC.

---

if your DHCP server goes down or compromised, all DHCP devices would go down with it.

---

As far as I can tell, that scenario has nothing to do with allocating static addresses outside of a dynamic range, all of which would be defined *internally* to a given DHCP server.