Re: [v6ops] Please review the No IPv4 draft

[Nick Hilliard <[e-mail]>]

On 15/04/2014 18:47, Ted Lemon wrote:
> On Apr 15, 2014, at 12:16 PM, Nick Hilliard <[e-mail]> wrote:
>> I think you need to go back to the drawing board on this draft.  As
>> I said before, stopping v4 DHCPREQUEST packets is a good idea and it would
>> be feasible to design a mechanism to implement it.  Beyond that, you're on
>> shaky ground.
> 
> Nick, if you want something like what you just said to actually be the
> outcome of the process, you need to give a clear technical objection
> that motivates that outcome.

I've written 10 emails on the topic in the last 24h, which is at least 9
too many, and probably 10.  These contain details on a wide variety of
issues, but they can be broadly summarised as:

helicopter view of draft issues:

the draft is poorly structured; the problem statement does not match the
solution which is presented; the justification for the overall aims of the
draft is weak; the consequences of the draft as defined in S5.3.1 through
S5.3.3 are ill thought out and have far-reaching consequences which look
extremely difficult to implement as well as being contentious from an
operational point of view; there is no proposed "v4-level" option which
matches the problem statement; the draft proposes that a remote signalling
mechanism should be allowed to completely shut down ipv4 services right
across an entire client machine - an issue which is well beyond the remit
of the ietf standards process; there is no security analysis of anything.

technical implementation issues:

the justification for the proposed technical solution (as distinct from the
overall aims) is almost non-existent;  the proposal suggests a back-door
mechanism to implement a protocol shutdown when a front-door mechanism
would be technically much simpler to implement; the draft does not provide
any protocol to implement this inter-process communication mechanism while
all parties agree that there is a serious back-end problem here; the draft
does not detail how or why it is appropriate for a kernel level protocol
(RA) to signal a widescale kernel/userland behavioural change for an O/S;
any real-world implementation of this draft will require changes to both
dhcpv6 and RA rather than a single protocol, which will result in serious
implementation problems;  there has been no discussion alternative
approaches to handle the problem (e.g. mac layer filters); there is no
option for a timeout in the protocol proposal; the proposal as it stands
will open implementers up to a wide variety of race conditions and
inconsistent states; the implementation will cause the interpretation of RA
and its interaction with DHCPv6 to become further complicated (sufficient
ill-defined / complicated at the moment that it needs an entire rfc to
describe it).

There's discussion of most of these points on the v6ops mailing list. If
there are any you want clarification on, please let me know and I'll do my
best to elaborate.

Overall, I view the proposal as being a bizarre approach to handling far
too large a problem space.  However, small bits of it may worth salvaging
and re-working from the ground up, hence the suggestion for the authors to
go back to the drawing board and re-think the problem set and potential
solution space from scratch.  As it stands, I do not believe that further
work on this draft would be productive.

Nick