the internal pull-ups is weak (about 100k). you can use them but the guaranteed speed will very slow (about 25 bit/s or less). with external 2k..4k pull-ups the speed is limited to 400 kbit/s.
also, remember that you need an external pull-up only at the data line in single-master topology keeping the clock line as push-pull at the master.
maybe matt and nick are both right about the clock-stretching feature but it is useful only in theory. i2c was designed so universal (again in theory) but in practice its behavior by design (without additional constraints) leads to the following failures:
driver level deadlock: as a result of a failure on the host, the device's state machine could "freeze" in a non-acknowledged state forever, and if you cannot "re-clock" the device the system fails in this service. this deadlock is manageable in either case you use open-drain or push-pull clock. linux i2c drivers typically manages that scenarios.
device level deadlock: as a result of a failure on the device, its state machine could "freeze" in the clock shrinkage phase, and if you cannot "re-drive" that the overall system fails. this deadlock is manageable only if you use (strong) push-pull clock or your i2c unit support a timeout mechanism with sensing of the clock. hardware support is always necessary to manage that scenarios.
also, the topic starter mentioned the concrete chip --- at32uc3b, which TWI unit does not support a timeout on clock shrinkage.
may be it seems like a hack but it is useful (the only simple?) hack if you design a real system which must be reliable and dependable instead of a toy class/home work which is not intended to work for long and good.
therefore my advice to jeremiah is:
1) use a pull-up at the data line, as strong as your master/slaves can drive;
2) use a push-pull at the clock line if your slaves can work on the target bus frequency;
3) use a clock frequency of the bus as the slowest slave support without the shrinkage;
and also as recommended:
4) use i2c only if another-interfaced devices do not exist, e.g. use spi instead of i2c;
5) always think in terms of reliability and dependability while you design electronics, especially, software-driven electronics.