Subject: Re: Fwd: New Version Notification for draft-ietf-6man-ipv6only-flag-02.txt

From: Nick Hilliard <[email-masked]>
Date: Sat, 8 Sep 2018 19:25:18 +0100

[returning to this point due to concerns raised during WGLC]

Brian E Carpenter wrote on 16/08/2018 23:42:
> On 2018-08-17 10:05, Nick Hilliard wrote:
>>>     o  In particular, this may overload switches in multi-segment
>>>        wireless networks because it will create IPv4 state for every dual
>>>        stack host.
>>
>> I'm not clear what you mean here.  Switches don't carry ipv4 state, and
>> creating ipv4 state in dual stack hosts is of negligible overhead (e.g.
>> sockets, etc).
> 
> 1) Switches may sometimes do things like ARP snooping and caching.
> 2) Any overhead is significant in a battery-limited device.

2) is continued repetition of the battery power consumption issue for 
wifi networks, which is already dealt with separately in your draft. 
This is not relevant to switch forwarding planes.

Regarding your assertion about switches becoming overloaded due to 
carrying ipv4 traffic, layer 2 switches do not carry ipv4 state in any 
meaningful sense.  It is technically misleading, bordering on flat-out 
incorrect, to suggest otherwise.

And even if it were correct in some sense, it wouldn't be relevant 
because on a network link with ipv4 services disabled, you wouldn't be 
doing any ipv4 snooping anyway, just ethertype filtering.

It is true that some switches perform certain types of frame snooping 
associated with ipv4, including DHCP snooping and dynamic arp 
inspection. This is handled based on explicit configuration by the 
switch operator, and I have never seen either option enabled by default.

The mechanisms varies from chipset to chipset, but generally involve a 
stateless process on the forwarding plane whereby packets of interest 
are punted up to the control plane via a qos policer so that the control 
plane CPU is not trashed.  The control plane will then do some 
processing, e.g. comparing against a static arp binding table in the 
case of dynamic arp inspection, or packet dissection in the case of DHCP.

"State", to the extent that it exists, refers solely to tiny memory 
structures held on the control plane of the switch.  In the case of DHCP 
snooping, these structures are informational; in the case of ARP 
snooping, they are generally pre-configured on the control plane, i.e. 
necessarily limited by the amount of configuration entered on the 
switch.  I.e. the configuration mechanism will prevent you from entering 
too many entries into that state table.  You will run out of 
configuration token space long before you run into RAM limits on the 
control plane.

Based on how the switch is configured, the control plane will then make 
a decision whether or not to forward the frame back down to the 
forwarding plane for transmission to the egress port.

There is no state maintained in the place where it matters, namely on 
the forwarding plane, i.e. where hardware resource limits are a very 
real issue and can present problems which can be difficult to handle.

The only area where this can cause issues is where you have excessive 
frame punting, causing high switch CPU usage on the control plane.  This 
is not going to be a problem in a situation where the operator wants to 
disable ipv4, as that operator will almost certainly not have enabled 
ARP inspection or DHCP snooping because, well, that would be dumb.

Even if the operator hasn't done this - which should be treated as a 
network misconfiguration - all reasonable quality managed switches have 
options for rate limiting punted packets, and these rate limiters are 
active by default.

Even then, the ARP inspection table should have been configured to be of 
zero size for that network segment, as ipv4 should be disabled, no?  And 
DHCP snooping creates no state to start with.

You need to remove this point completely from the draft.

Nick