Embedding Globally-Routable Internet Addresses Considered Harmful
draft-ietf-grow-embed-addr-05

[Ballot comment]
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

[Ballot comment]
>    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.

[Ballot comment]
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").

[Ballot comment]
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.

[Ballot discuss]
This document is too vague:  It says "don't do that", but it doesn't explore the reasons why vendors feel that it is necessary to embed globally routable IP addresses instead of using DNS names, and it doesn't suggest alternatives. 

Also, the continue use of the term "globally routable" might be interpreted to imply that embedding link-local or net 10 addresses is okay.

[Ballot discuss]
I think the Introduction needs re-wording, as it might appear that the author is
against the embedding of IP addresses *for use as routable addresses by the device*
as opposed to *for use as service addresses reachable by the device".  I suggest
re-phrasing the initial statement:

  Vendors of consumer electronics and network gear have produced and
  sold hundreds of thousands of Internet hosts with globally routable
  Internet Protocol addresses embedded within their products' firmware.

with:

  Vendors of consumer electronics and network gear have chosen to use
  hard-coded Internet Protocol addresses for certain services which they
  believe their devices will need to access; a recent example was the embedding
  of an IP address for an NTP host within the firmware of a product
  which needed access to time services.

and go on from there.


I also believe this statement, despite the nod to Heraclitus, is not really well phrased:

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
  future states cannot be fully explored, one should avoid assumptions
  regarding the longevity of our current Internet.


It seems like a reference to need to question the stability of any specific
topology would be clearer than "the longevity of our current Internet".  The
points made above that IANA might not be able to reassign blocks in
the face of this practice are clear, and it seems more important to reinforce
and generalize them than to question whether an Internet with a different
topology is or is not our current Internet.

[Ballot discuss]
The second paragraph of the Security Considerations discusses remote
  control mechanisms by which Internet host configuration can be changed
  without the involvement or knowledge of the operator or user.  The
  paragraph says:
  :
  : If such a scheme is implemented, this should be fully disclosed to
  : the customer, operator, and user so that an informed decision can be
  : made, perhaps in accordance with local security or privacy policy.
  : Furthermore, the significant possibility of malicious parties
  : exploiting such a remote control mechanism may completely negate
  : any potential benefit of the remote control scheme.
  :
  This does not go far enough.  While this is not the primary focus of
  this document, I think that we should not only require disclosure of
  such a feature, we should also require the ability to turn it off.

[Ballot discuss]
The second paragraph of the Security Considerations discusses remote
  control mechanisms by which Internet host configuration can be changed
  without the involvement or knowledge of the operator or user.  The
  paragraph says:
  :
  : If such a scheme is implemented, this should be fully disclosed to
  : the customer, operator, and user so that an informed decision can be
  : made, perhaps in accordance with local security or privacy policy.
  : Furthermore, the significant possibility of malicious parties
  : exploiting such a remote control mechanism may completely negate
  : any potential benefit of the remote control scheme.
  :
  This does not go far enough.  While this is not the primary focus of
  this document, I think that we should not only require disclosure of
  such a feature, we should also require the ability to turn it off.

[Ballot comment]
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.