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

[Joe Touch <[e-mail]>]

PS - here's what *I* think would be required to fix this doc, at a minimum.

- make it clear that this is about either NATs, L4 filtering 
(firewalls), or L4 port-based forwarding, not IP forwarding (the latter 
is a well-defined term and does not include L4 ports)

- make the requirement about a network *device*, not a network *provider*

- explain the corner cases in more detail
	you mention a few cases here, but it seems like you need to
	specify a length for nearly every protocol payload because
	you're claiming that you have enough information to handle
	the IP header, the IP options, and the next *header* (at least
	the most interesting parts of it).

	There are a bunch of cases that are common enough that they
	ought to be covered:
		IPv6 (just the inner IPv6? and its HBH?)
		IPv4 (any options?)
		GRE
		MPLS

	What about the TCP header? why stop at just the ports?
	might a future operator want to block traffic on whether
	it used authentication? or SACK?

	What about ICMP - why not also its payload? How far in?

- explain what to do if the chain is too long to see what you want

	MUST forward seems the only viable alternative to me,
	but if you disagree, propose an alternate and justify it

	if you don't forward, then you ought to be sending ICMP errors
	(subject to rate control)

- correct some of the other errors

	IPv6 has HBH headers for exactly the reasons you cite - to limit
	how much of the chain needed to be examined. What really changed
	is the desire for port-filtering and port-forwarding devices.

	IPv4 makes this simpler because the 'jump' to the end of the
	chain is in the header in a fixed location.

	This has nothing to do with ASIC vs. multicore software
	processing (e.g., on a NPU). It has to do with a fixed jump
	vs. a chain of jumps. ASICs and multicore software can
	either one, but the space cost is higher and variable, and the
	time cost is higher and variable.

Joe