ietf
[Top] [All Lists]

Re: Last Call: draft-carpenter-renum-needs-work (Renumbering still needs work) to Informational RFC

2009-09-10 07:20:22
Dear Authors & IESG,

Congratulations for providing us a comprehensive and interesting piece
of work that describes an abundance of issues that face administrators
who need to renumber their networks. 

I have several comments about this draft.  At a high level, I wonder
whether in fact some of the information is worthy of a deeper review,
perhaps in follow-on work.  The conversation on DNS Pinning alone seems
to warrant its own effort.  I can see that there must have been great
thought about how to organize information, considering that security
considerations run high when taking any configuration from the network,
even if that is as simple as a DNS query, as described in the doc.

In Section 5.1.1, the authors discuss an ambiguous behavior involving
DHCPv6 versus SLAAC and the go on to say:

   Until this ambiguous behaviour is clearly resolved by the IETF,
   operational problems are to be expected.  Also, it should be noted
   that on an isolated LAN, neither RA nor DHCPv6 responses will be
   received, and the host will remain with only its self-assigned link-
   local address.  One could also have a situation where a multihomed
   network uses SLAAC for one address prefix and DHCPv6 for another,
   which would clearly create a risk of inconsistent host behavior and
   operational confusion.
  

Would the authors care to clarify what operational problems could be
expected regarding the ambiguity, and what the risk of inconsistent host
behavior would be, and what recommendations they would have (if any) to
resolve those issues?  I feel teased ;-)

In Section 6.1 the authors discuss SHIM6.  I draw their attention to a
paper given by Richard Clayton at this year's Workshop on Economics and
Information Security (WEIS09) which can be found at the following URL
that discusses economic road blocks to deploying SHIM6:
http://weis09.infosecon.net/files/135/index.html.  My suggestion is that
this work be considered as a reference.  During his presentation, Dr.
Clayton suggested that perhaps we have Economics Considerations in our
protocol specifications.  While I don't think that's appropriate, the
analysis is enlightening.

I also believe that there is an elephant that remains in the living
room, with regard to Section 6.  There is no mention of the work being
considered within the RRG, or that of the LISP WG.  A principle benefit
of LISP and certain similar approaches is the near complete obviating of
the need to renumber.  Having bashed my own head on this problem
numerous times, I think it's important to ask the question of whether we
should just stop asking networks to do so, and architect/engineer
accordingly.

Thanks again for your efforts,

Eliot


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf