Re: [v6ops] Please review the No IPv4 draft

[Nick Hilliard <[e-mail]>]

On 17/04/2014 15:57, Ted Lemon wrote:
> On Apr 17, 2014, at 7:14 AM, Nick Hilliard <[e-mail]> wrote:
>> From what I can see, there was no initial justification to use v6 transport
>> other than a declarative "it shall be so!" pronouncement, and in this
>> situation it is reasonable to question this decision in v6ops, particularly
>> as it will cause operational problems as outlined by a bunch of people.
> 
> Sure, it's reasonable to question the decision, and the working group
> did ask for feedback, so there's nothing wrong with providing feedback.
> However, my point is that v6ops doesn't get any special veto power over
> this if you don't raise substantive objections.

the point people are raising is that there appears to be a considerable gap
between your understanding of "substantive objections" and theirs.

>> this is also a valid concern.  I can see no reason why anyone would heed an
>> unauthenticated signal to entirely shut down all ipv4 services o/s wide on
>> their ipv4-enabled client (or even no-ipv4 options 1-2 for that matter),
>> when we already have the existing option for operators to fully satisfy all
>> aims of this draft by declining to forward ethertypes 0x0800 and 0x0806.
>> Simple and enforceable are both good engineering principals to aspire to.
>> Complex+advisory+piles of failure modes+controversial need a much greater
>> level of justification, which is notably absent from this draft.
> 
> Noted.   I think it would be good to have text in the document that
> explains why this isn't the proposed solution, so that it can be
> evaluated on the merits and we don't have to speculate.

As the draft demands that a single unauthenticated packet can shut down
ipv4 services on a client device either completely (as specified in 5.3.3)
or almost completely (5.3.2), both options will need a detailed security
analysis to describe how packets of this form cannot be abused by either an
malicious operator or by rogue packets caused by access domain
misconfiguration.  Also, given the extraordinary nature of these
requirements, the justification for including them in an internet standards
track document will need to be similarly extraordinary.

Nick