Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05

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

> Maybe the authors
> can take the time to actually experiment with the draft

Well, Bjoern implemented it for FreeBSD. We've checked with scapy that it doesn't break current hosts. But to experiment on a large scale, we'd need routers, Windows and Apple hosts on board. You know that's impractical for a pre-standard feature at this level of the stack.

Regards
   Brian

On 08-May-19 22:39, Philip Homburg wrote:
>>> But nobody is doing any work on what IPv4 should look like in the future.
>>
>> I don't understand that sentence. IPv4 is a legacy protocol,
>> so it will simply fade away.
> 
> If we are ready to let it fade then we would not be discussing a draft that
> modifies IPv4 behavior claiming that it is good for (among others)
> battery life.
> 
> Yes, just let IPv4 fade away and kill this draft. We don't need new protocol
> that deals with IPv4.
> 
>> The nail has never been unknown, but some people claim it's too
>> small to be worth hammering.
> 
> The nail has changed. Early on in sunset4 it would just disable IPv4
> unconditionally. Over time the nail has become smaller and smaller and now
> we have text basically doesn't mandate anything anymore.
> 
>>>   Because there is no analysis from an IPv4 perspective, we don't actually
>>>   know if this draft is needed and how much effect it will have. 
>>
>> We know that we're talking about a few percent of the traffic on an
>> IPv6-only network. Quantifying the effect on battery life is not
>> a reasonable task.
> 
> The draft has two bullet points on battery. Battery life of hosts has been
> used often to argue for this draft. And now the effect cannot be quantified?
> 
> Maybe it is time to actually start with a problem statement that can be
> measured?
> 
> Of course the same applies to how big of an issue the extra network 
> traffic is.
> 
>> It's unclear to me what that accident might be, apart from what is
>> already in the security considerations.
> 
> The security section does not mention accidents. There is a risk that somebody
> will accidentally turn this flag on on a official router. In the field it is
> very unlikely that people will relate weird IPv4 failures to something that
> is sent in an RA.
> 
> I don't know if the security considerations are intentionally incomplete,
> but they clearly reflect the hammer looking for a nail. Maybe the authors
> can take the time to actually experiment with the draft and have 
> somebody look at it who knows about security.
> .
>