Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-01.txt

[Joe Touch <[e-mail]>]

On 7/5/2013 7:06 AM, Nick Hilliard wrote:
> On 05/07/2013 14:35, Joe Touch wrote:
>> ... then limiting the forwarding chain won't help because these aren't
>> forwarded by that router.
>
> then your understanding of modern routers is incorrect.
>
> Let's say you have an IPv6 address on a router interface - it doesn't
> matter if it's used for management or not

Agreed. Packets addressed *to* the router need to be fully processed.

That has nothing to do with packets not addressed to the router. Those 
packets pass through the forwarding plane.

The draft talks about this being a forwarding plane issue.

Your explanation has nothing to do with that. However, I can still shut 
down your router any number of ways, by sending lots of interesting 
things in those first 128 bytes that cause the router to overload - 
e.g., fragments to reassemble, source routes to process, etc.

So limiting the chain for packets addressed *to* the router solves the 
problem of how much data to copy before you know you need to something 
else with the packet. But you can easily be asked to do a lot more than 
the router can handle once you copy that. So you've solved the copy 
problem, but not much else.

> In order to implement CoPP/RE firewalling, we need hardware ACL support to
> be able to distinguish between the sorts of packets that we want to see and
> the ones we don't.  In practice, this means implementing sophisticated ACL
> + QoS support in hardware. Consequently, this means that we need the
> ability to inspect reasonably deeply into ipv6 packet headers.

Hardware does not imply short headers. Wanting to do fast copies of 
subsets of a packet does - independent of hardware vs. software.

> ...All you need to know is the
> ipv6 address of any interface on the box, and you can trivially trash it
> remotely.

Whether that's true does not seem to depend on the header chain length, 
though.

Joe