The topic of static IP address allocation came up today between a coworker and I, and we had differing ideas on how it should be done.
This would be static IP's for our broadband DSL users on non-portable upstream assigned IP space.
One method would be to have all our customers run a DHCP client, and those who wanted a static IP would get one reserved in the DHCP server via MAC address.
The other method would be to staticaly route their host IP (or a small range) down their pvc and exclude it from the DHCP server range.
Some of our arguments:
Managing end user MAC addresses for static IP users would be a big hassle. Every time an end user changes a NIC, swaps a server out, buys a new computer, they would need to put a call in because their MAC had changed.
Having DHCP assigned statics allows us to change DNS server IP's on the fly with minimal implications. It would also allow us to reassign new IP space without breaking everything (end user mail/dns/etc. would break). Worst case senario is an IP subnet change would occur, the user would DHCP their new "static" IP breaking any server services, but would still be able to connect to the Internet.
There were other arguments about possible DHCP spoofing agains't static IP and such.
IANAAtmGuy, but could it potentially be possible to use DHCP and map IPs
to PVCs instead of to the end user's MAC address? Even if the end user's
MAC address changes, the PVC number shouldn't...
However, this does get complex when you have multiple machines on a PVC.
-C
It's possible theoretically but not in the real world. Nice idea though. Your major headache is that DHCP isn't defined to work that way. 
Right now the DHCP model assumes that any static mapping can depend upon a hardware identifier, usually the MAC. It wouldn't be that hard to define an appropriate DHCP option to substitute something more arbitrary like a VC identifier, but to my knowledge no one has done so. Beyond that, you've got to work with the problem that neither endpoint of a traditional DHCP session is ATM-aware. Generally a customer workstation is querying a DHCP server somewhere in an ISP server farm, and the ATM VC covers only an intermediate part of the path between them. I suppose that one could run a smaller DHCP server within each VC-terminating aggregation router, but that has its own set of administrative headaches, and again I don't believe anyone has done that. Even if that did work, you'd still have the problem that ATM VC identifiers aren't globally unique, and keeping them locally unique has scaling problems. And, as mentioned before you have problems if you have multiple addresses on one VC. If the access (DSL) provider is not also the ISP, it gets even worse. In other words, DHCP by ATM VC is a nice mind exercise but don't bother asking for it.
Not that I have any other solution in mind.
--eric
(speaking for myself and not representing my employer in any way)
Perhaps I'm misunderstanding either you, Eric, or the situation, but
DHCP client can supply a host name, can they not? And I thought
servers could use that to look up for a fixed address.
Yes, it's configurable, rather than fixed, but at least it's *there*.
Would this not solve the gentleman's problem?
Cheers,
-- jra
Hmmm, you're right. It gets supplied as a form of the "client identifier", but I've never seen a host name used, and somehow I hadn't notice on my recent reading of RFC 2131 that it even gives "DNS name" as an alternate possible use of the "client identifier" option. [RFC 2131, page 8 et al] I bow before your power of recollection.
I'm left wondering how one would enforce correct configuration of host name as the client identifier? What would prevent one customer from configuring a machine to steal someone else's static address? That wouldn't be much use for getting a second address but it would make for a dandy denial of service against the "someone else".
I suppose that, as long as the client identifier can be arbitrary, that one could issue a difficult-to-predict client identifier for each IP address. Tell the customer it's their IP address contract number? You're right, at least it's already there, even if the ISP discovers they have to modify some DCHP client software in order to implement it.
(I'm humbled)
--eric
>Perhaps I'm misunderstanding either you, Eric, or the situation, but
>DHCP client can supply a host name, can they not? And I thought
>servers could use that to look up for a fixed address.
>
>Yes, it's configurable, rather than fixed, but at least it's *there*.
>
>Would this not solve the gentleman's problem?
Hmmm, you're right. It gets supplied as a form of the "client identifier",
but I've never seen a host name used, and somehow I hadn't notice on my
recent reading of RFC 2131 that it even gives "DNS name" as an alternate
possible use of the "client identifier" option. [RFC 2131, page 8 et
al] I bow before your power of recollection.
Not bad, for my first day back after almost 2 years...
I'm left wondering how one would enforce correct configuration of host name
as the client identifier? What would prevent one customer from configuring
a machine to steal someone else's static address? That wouldn't be much
use for getting a second address but it would make for a dandy denial of
service against the "someone else".
You wouldn't, of course. Such was the subtext of my comment on it
being "changeable". But you can change some MAC addresses, too.
As for DOS in that context, short of PK authentication, you're probably
still SOL.
I suppose that, as long as the client identifier can be arbitrary, that one
could issue a difficult-to-predict client identifier for each IP
address. Tell the customer it's their IP address contract number? You're
right, at least it's already there, even if the ISP discovers they have to
modify some DHCP client software in order to implement it.
I believe there's actually even an EditTheRegistry<tm> was to set
that on Win9x.
(I'm humbled)
You do me too much honor, sir.
Cheers,
-- jra