Eliot,
Now that Last Call is over, some considered replies to
your thoughtful comments.
On 2009-09-10 23:19, Eliot Lear wrote:
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.
Thanks!
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.
That could be true, we'd be glad to see follow-on work, which is why
we include a gaps section. This document is probably long enough, however.
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 ;-)
This has been a long-running hot topic in IPv6-land. Look at Thomas Narten's
explanation and plea for action at
http://www.ietf.org/mail-archive/web/ipv6/current/msg09826.html
We really don't feel the present draft is the place to recommend
a particular solution. Thomas suggests several in that email.
To a simple mind, it seems better to choose any of them rather
than leave things ambiguous. For the present draft, we can add some words
about the operational annoyances from this ambiguity; but we believe
that 6man should resolve it.
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 (Brian) had the chance to discuss that paper personally with Richard.
He was unlucky in that it came out soon before the SHIM6 RFCs were
published, so he was out of date in saying that SHIM6 wasn't standard.
But apart from that I like the paper. However, I'm not sure what it
adds here. All we say is that SHIM6, if deployed, would lessen the
pain of renumbering. I think we all know that's a significant "if".
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.
Yes, in the new version there will be a mention of work in progress
that will reduce (not eliminate) the need for renumbering, and LISP is
one possible example. But as Ran Atkinson said earlier, a real discussion
of those solutions seems out of scope.
On 2009-09-12 19:26, Eliot Lear wrote:
The hypothesis of the document is there will always be circumstances in
which partial or complete renumbering is needed, whatever such technologies
may be available. We should maybe make that clearer in the Introduction.
I think the fundamental issue is in Section 6, where you talk about
"Other Work". Where do you draw the line? While I would accept the
notion that conceivably NETCONF could help, you may actually wish to
trim that section considerably.
We can agree that some of it is speculative, but we think it's reasonable
to refer to ongoing work. If MANET solutions in particular could be
generalised, renumbering would probably vanish as an issue. (We're not
particularly optimistic about this.)
I also think you should test your hypothesis, and discuss its limits.
You mean the hypothesis that NETCONF could be used? That would be a major
project in itself.
Brian, Ran, Hannu.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf