Embedding Globally-Routable Internet Addresses Considered Harmful
RFC 4085
Yes
No Objection
(Alex Zinin)
(Bert Wijnen)
(Bill Fenner)
(Jon Peterson)
(Russ Housley)
(Scott Hollenbeck)
Abstain
No Record
Note: This ballot was opened for revision 05 and is now closed.
David Kessens Former IESG member
Yes
Yes
(2004-09-15)
Unknown
Comments from Pekka Savola from the ops directorate:
I agree with Steve's comment, and I think the document could be
reinforced to include more discussion of what you can achieve with
DNS.
That is, the document seems to assume that an alternative to embedding
IP addresses like 1.2.3.4 is embedding hostnames like
ntp.university.edu. This is wrong. The real alternative is for the
vendor foobar to do use ntp.foobar.com, or use SRV records in the
domain pointed by the search path.
These issues have been discussed partially in draft-ymbk-dns-choices
and (in different context) draft-palet-v6ops-tun-auto-disc.
Thus I think the document would be much more useful if the
recommendations section would be beefed up.
Alex Zinin Former IESG member
No Objection
No Objection
()
Unknown
Bert Wijnen Former IESG member
No Objection
No Objection
()
Unknown
Bill Fenner Former IESG member
No Objection
No Objection
()
Unknown
Harald Alvestrand Former IESG member
No Objection
No Objection
(2004-09-16)
Unknown
Reviewed by Spencer Dawkins, Gen-ART. Personally, I believe the doc could have recommended DNS names (long ones!)instead of sniffing that they "are not permanent either" - the continued use of a DNS name that is no longer registered is not so harmful as the continued re-use of an IP address. But I won't block on that - I assume GROW had an opinion about it that is reflected in the document, and I know it can be debated multiple ways. Spencer's review: This is good work (just about ready for BCP). There's a dangling "Figure 1" just before the Introduction that doesn't seem to have a figure associated with it. "well know public" should be "well known public". I don't know if it's worth pointing out that using DNS names instead of IP addresses also provides better NAT-traversal characteristics for protocols that don't embed IP addresses (fourth paragraph of "Recommendations").
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Margaret Cullen Former IESG member
(was Discuss)
No Objection
No Objection
(2004-09-17)
Unknown
I decided that my initial discuss was unwarranted and removed it.
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Scott Hollenbeck Former IESG member
No Objection
No Objection
()
Unknown
Ted Hardie Former IESG member
(was Discuss)
No Objection
No Objection
(2004-11-05)
Unknown
Nit in version 4: An alternative to inventing vendor-specific domain naming conventions for a product's service identifiers is to utilize SVR resource SVR-->SRV
Steven Bellovin Former IESG member
Abstain
Abstain
(2004-09-10)
Unknown
I've chosen to abstain, but I'm very close to a DISCUSS on this document. While the complaints made are valid, the authors offer no reasonable, scalable alternative. If addresses can't be used and domain names can't be used, what can be done? The document suggests using DHCP-assigned values, which is ridiculous -- far too many ISPs would have to be persuaded to supply reasonable values, which would create an intolerable burden for small vendors.
Thomas Narten Former IESG member
No Record
No Record
(2004-09-16)
Unknown
> This document denounces the practice of embedding references to > unique, globally routable IP addresses in Internet hosts, describes > some of the resulting problems, and considers selected alternatives. same for private addresses? > Embedding globally unique IP addresses taints the IP address blocks > in which they reside, lessening the usefulness and portability of > those IP address blocks and increasing the cost of operation. Interesting definition of "portable"; usually, portable means owned by end site, in which case hard-wiring an address works just fine... > Internet host and router designers, including network product > manufacturers, should not assume that their products will be deployed > and used in only a single global Internet that they happen to observe > today. A myriad of private or future internets in which these > products will be used may not allow those hosts to establish > end-to-end communications with arbitrary hosts on the global > Internet. Since the product failure modes resulting from unknown This is a strange assertion. "future internets", as in plural? Not sure about the end-to-end comment either.