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

[[e-mail]]

> > I have no problem at all with the specifications evolving to make
> > the Internet work better. But this isn't what we are talking about
> > here. Rather, we are talking about changing the specifications for
> > the convenience, not of those using the Internet, but of those
> > building the infrastructure.
> 
> That is correct. Claims that this is about a technical problem are false.
> 
> E.g., it's incorrect to claim that this is a forwarding issue. It is a 
> *firewall* (and possibly NAT) issue.
> 
> The problem is that IPv6 was designed to make it easier to add and 
> delete options and "shim" layers between IP and transport - which it does.
> 
> *Everything* an IP *router* ***requires*** to forward a packet is 
> visible in the main IP header or the HBH options. The sum of the two is 
> already limited to 40 (main header) + 256 (HBH), so it's already the 
> case that a compliant IP router never needs to look beyond the first 296 
> bytes to forward a packet.

Looks like we need to come up with a new term here.

A pure IPv6 router, as you define it, is completely useless to me.

My real, operation requirements include IPv4 / IPv6 forwarding for
multiple 10 Gbit/s links *and* very basic, stateless access lists 
that must be able to look at address *and* L4 info (port numbers).

I believe that when most operators talk about routers, they include
this or similar capabilities - simply because that is a necessity in
order to run a production network.

> So let's please be very clear about what _this_ draft is saying - it is 
> NOT about making routers do something that routers *need* to do.

It is about making what *operators* call routers useful in real life.

Your definition of router is not the same as that of many operators.
Let's make a note of this and move on.

Steinar Haug, AS 2116