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

[Brian E Carpenter <[e-mail]>]

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.