Subject: [RRG] The use of UDP in LISP

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 7 Dec 2007 17:23:01 -0800

Dino,

<recap>

Basically, you need a UDP header so that boxes that sit between the  
ITR and ETR that don't know about LISP will be able to do load  
balancing of data streams towards an ETR. However, you're really not  
looking to calculate a checksum over the resulting UDP packet. In IPv4  
UDP checksums are optional, but not in IPv6.

When a router (switch?) has multiple links that are equal cost paths  
toward a certain destination, you can generally let the router load  
balance across these links, but to avoid packet reordering, the router  
creates a hash of at least the destination IP address (possibly also  
the source IP address) and the source/destination port numbers if the  
packet is TCP or UDP and sends packets with the same hash over the  
same output port. If the packet isn't TCP or UDP the router can only  
look at the destination address and possibly the source address so  
load balancing becomes a lot coarser to the point of possibly not  
working to a usable degree anymore.

</recap>

I think this can be solved by giving each ETR a small range of  
addresses rather than a single one. For instance, if the mapping  
system tells the ITR that an ETR has 240.0.0.5/29 then the ITR could  
send one flow towards 240.0.0.0, another flow to 240.0.0.1 and so on.

This way, the checksum issue goes away and we also get to save 8 bytes  
per packet.

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Shane Amante <[email-masked]>
Date: Sat, 8 Dec 2007 11:23:52 -0700

Iljitsch,

On Dec 7, 2007, at 6:23 PM, Iljitsch van Beijnum wrote:
> looking to calculate a checksum over the resulting UDP packet. In  
> IPv4 UDP checksums are optional, but not in IPv6.
>
> balance across these links, but to avoid packet reordering, the  
> router creates a hash of at least the destination IP address  
> (possibly also the source IP address) and the source/destination  
> port numbers if the packet is TCP or UDP and sends packets with the  
> same hash over the same output port. If the packet isn't TCP or UDP  
> the router can only look at the destination address and possibly the  
> source address so load balancing becomes a lot coarser to the point  
> of possibly not working to a usable degree anymore.
>
> </recap>
>
> This way, the checksum issue goes away and we also get to save 8  
> bytes per packet.

A few things:
1)  As one of the instigators to get Dino to move to the UDP approach  
for load-balancing, I can say we discussed this, but it was ruled out,  
since it creates administrative overhead for operators/administrators  
to acquire and /properly configure/ a large enough subnet on the ETR  
to get 'decent' load-balancing over LAG's, etc. through the core.
2)  The sites where ETR's (or ITR's) are located have little and, more  
likely, no incentive to set-up a properly sized subnet to get "even"  
load-balancing through my core.  (Heck, they may not even be my  
customer, what do they care?!)  It's much, much, much better to have  
an automatic mechanisms that's just there, that they don't have to  
think about and much less to configure.

-shane

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 10 Dec 2007 00:53:02 -0800

> IPv4 UDP checksums are optional, but not in IPv6.

To be general, any tunneling mechanism looks to core routers as a  
single flow. And if they can't look deeper into the packet, they  
cannot load-split efficiently on LAGs.

The checksum is orthogonal to the discussion, but I guess if you are  
stating that UDP is an advantage to solve LAGs but is a disadvantage  
because of requiring checksum computation for IPv6, then I agree.

> of possibly not working to a usable degree anymore.

Right.

> send one flow towards 240.0.0.0, another flow to 240.0.0.1 and so on.

In popular routers, that would need to be 16. That is too much  
administration and a wastage of address space. There is nothing wrong  
with UDP encapsulation.

> This way, the checksum issue goes away and we also get to save 8  

Sounds like a really bad tradeoff to me.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 10 Dec 2007 00:59:33 -0800

> Sounds like a really bad tradeoff to me.

And by the way, UDP-Lite is actually heavier (for routers) than UDP  
with checksum of 0. So I feel UDP-Lite is not an option.

Dino

---

From: Lars Eggert <[email-masked]>
Date: Mon, 10 Dec 2007 13:45:22 +0200

> with checksum of 0. So I feel UDP-Lite is not an option.

Could you elaborate a bit, please? It may be the jetlag, but I can't  
follow.

Lars

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 10 Dec 2007 10:51:21 -0600

Thus spake "Iljitsch van Beijnum" <[email-masked]>
> In IPv4 UDP checksums are optional, but not in IPv6.

That's because IPv4 has its own header checksum and IPv6 doesn't.  The work 
for IPv6 with a UDP checksum is no worse than for IPv4 without a UDP 
checksum.  IIRC, that was intentional.

There's reasons to debate UDP encapsulation, e.g. load balancing, but 
checksum costs is not one of them.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 10 Dec 2007 09:17:35 -0800

> Could you elaborate a bit, please? It may be the jetlag, but I can't  

Now with UDP-Lite, which we did not have to do with checksum-0-based- 
UDP:

o Check on another field to determine how many bytes we have to  
checksum.
o Build a pseudo-header which prepends the checksummed data.

Dino

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 10 Dec 2007 21:51:43 +0100

On 8 dec 2007, at 19:23, Shane Amante wrote:

>> system tells the ITR that an ETR has 240.0.0.5/29 then the ITR  
>> could send one flow towards 240.0.0.0, another flow to 240.0.0.1  
>> and so on.
>>

> 1)  As one of the instigators to get Dino to move to the UDP  
> approach for load-balancing, I can say we discussed this, but it was  
> ruled out, since it creates administrative overhead for operators/ 
> administrators to acquire and /properly configure/ a large enough  
> subnet on the ETR to get 'decent' load-balancing over LAG's, etc.  
> through the core.

So? If we put in the spec that you MUST assign a /29, /28 or what have  
you to an ETR and all ITRs automatically use that entire address  
range, they'll simply have to do it or it won't work.

The lack of address space doesn't sound convincing to me either, today  
everyone with an AS number has at least a /24 and obviously not  
everyone with an AS is going to run ETRs as that way we don't save any  
routing table state.

I'm not convinced that the load balancing issue amounts to much in the  
first place, by the way. In the vast majority of cases traffic will  
come from many different places so load balancing will happen without  
assistence.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 10 Dec 2007 21:56:27 +0100

> That's because IPv4 has its own header checksum and IPv6 doesn't.

If you say so...

> The work for IPv6 with a UDP checksum is no worse than for IPv4  
> without a UDP checksum.

Huh? If there is no checksum you simply process the packet -> done. If  
there is a checksum, you need to sum all 16-bit words in the packet,  
which is a somewhat expensive operation if you can't do it while  
you're copying the packet anyway.

I guess you could optimize this by taking the checksum from the TCP or  
UDP payload of the inner packet and just do an incremental checksum of  
everything that's not part of that checksum (only a few IP header  
fields and the new UDP and other headers that are inserted). But not  
doing a checksum is a much more attractive proposition.

---

From: Shane Amante <[email-masked]>
Date: Mon, 10 Dec 2007 21:49:29 -0700

On Dec 10, 2007, at 1:51 PM, Iljitsch van Beijnum wrote:

>> approach for load-balancing, I can say we discussed this, but it  
>> was ruled out, since it creates administrative overhead for  
>> operators/administrators to acquire and /properly configure/ a  
>> large enough subnet on the ETR to get 'decent' load-balancing over  
>> LAG's, etc. through the core.
>
> So? If we put in the spec that you MUST assign a /29, /28 or what  
> have you to an ETR and all ITRs automatically use that entire  
> address range, they'll simply have to do it or it won't work.

You might certainly be able to say MUST, but that doesn't mean  
everyone will configure ITR/ETR's that way.  As one example, look at  
the plethora of RFC's related to Internet security that everyone MUST/ 
SHOULD/etc. follow and, unfortunately, don't ...

Furthermore, I, and lots of others, would much rather not be "protocol  
police" and chase people around telling them to fix their ITR/ETR  
deployments (by assigning a /29, /28, etc.), when we can easily  
accommodate it in the protocol automatically and for very, very, very  
little overhead.

> The lack of address space doesn't sound convincing to me either,  
> today everyone with an AS number has at least a /24 and obviously  
> not everyone with an AS is going to run ETRs as that way we don't  
> save any routing table state.
>
> I'm not convinced that the load balancing issue amounts to much in  
> the first place, by the way. In the vast majority of cases traffic  
> will come from many different places so load balancing will happen  
> without assistence.

As someone who has lived with the very acute pain of unfair load- 
balancing for the past several years, it is a very real problem -- the  
biggest problem today, and for the last few years, is EoMPLS.  Only  
just recently has someone offered a couple of suggestions to alleviate  
the pain of EoMPLS:
http://tools.ietf.org/html/draft-bryant-filsfils-fat-pw-00
While I don't necessarily agree with the recommended approaches in  
that draft, I (and other operators) agree that it's a very real  
problem and needs to be solved.

Back to LISP, and any other proposal which uses tunneling, there will  
lots of cases where medium- to large- Enterprises and/or SP's are  
sending traffic from their network, tunneled through an ITR, to a  
decently sized content/server-farm or other SP's with ETR's.  Don't  
assume that because either of the downstream/edge Enterprise's or SP's  
have 2 (or more) upstream SP's that they will always be evenly load- 
splitting their traffic between those two providers.  When either  
Enterprise A or SP B has one of their access circuits cut, or when one  
of the upstream SP's is experiencing congestion, etc. then Enterprise  
A or SP B will move all, or nearly all, of their traffic onto the  
other upstream SP.  This results in a lot of traffic being sourced  
from a single ITR toward a single ETR.

One other point to consider: if you are an owner of that ITR or ETR  
and you don't use this UDP encapsulation scheme, you will have very,  
very, very little input into the 'outcome' of that load-hashing  
algorithm in each core router that your tunneled traffic goes through,  
(it would just use the outermost src & dst IP's).  When your traffic  
lands on a congested component-link, you're likely to be quite upset  
about that, but the SP that owns that core router is most likely going  
to be unable to do anything about it.  Instead, the "quick fix" will  
be for end-users of ETR's (and ITR's) to change their load-splitting  
policy for EID -> RLOC mappings, which means they will want/need to  
quickly change state of the mapping system to fix the congestion  
problem.  Now, why we would want to add this additional "emergency"  
bursty traffic load on the mapping system if it can largely be  
avoided, (and, instead, the mapping system can deal mostly with longer  
timescale traffic engineering)?

-shane

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 11 Dec 2007 16:19:34 -0500

On Dec 10, 2007, at 3:56 PM, Iljitsch van Beijnum wrote:

> Huh? If there is no checksum you simply process the packet -> done.  
> If there is a checksum, you need to sum all 16-bit words in the  
> packet, which is a somewhat expensive operation if you can't do it  
> while you're copying the packet anyway.
>
> I guess you could optimize this by taking the checksum from the TCP  
> or UDP payload of the inner packet and just do an incremental  
> checksum of everything that's not part of that checksum (only a few  
> IP header fields and the new UDP and other headers that are  
> inserted). But not doing a checksum is a much more attractive  
> proposition.

I think that this will require a modification to (ugh!) RFC 2460 -  
which says
>
>      o  Unlike IPv4, when UDP packets are originated by an IPv6 node,
>         the UDP checksum is not optional.  That is, whenever
>         originating a UDP packet, an IPv6 node must compute a UDP
>         checksum over the packet and the pseudo-header, and, if that
>         computation yields a result of zero, it must be changed to hex
>         FFFF for placement in the UDP header.  IPv6 receivers must
>         discard UDP packets containing a zero checksum, and should log
>         the error.
>

Dino Farinacci has suggested this text :

o When a IPv6 router is using a UDP header as part of a tunnel  
encapsulation,
   it MAY compute a UDP checksum. The IPv6 router on the other side  
of the
   tunnel receives a UDP checksum of non-zero it MUST compute the  
checksum
   according to [UDP-spec]. When an IPv6 router uses a UDP header for  
tunnel
   encapsulation and sets the UDP checksum field to 0, the IPv6  
router on the
   other side of the tunnel MUST not compute the checksum on the  
received
   packet. This procedure allows tunnel routers to behave the same for
   tunnel encapsulating IPv4 and IPv6 packets.

At the least AMT and LISP would require this, and I suspect that  
there will be others.

Regards
Marshall

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Dec 2007 13:13:22 +1300

On 2007-12-12 10:19, Marshall Eubanks wrote:
...
>   it MAY compute a UDP checksum. The IPv6 router on the other side of the
>   tunnel receives a UDP checksum of non-zero it MUST compute the checksum
>   according to [UDP-spec]. When an IPv6 router uses a UDP header for tunnel
>   encapsulation and sets the UDP checksum field to 0, the IPv6 router on 
> the
>   other side of the tunnel MUST not compute the checksum on the received
> At the least AMT and LISP would require this, and I suspect that there 
> will be others.

I don't actually understand the "require". If you'd written "People
coding AMT and LISP would find this convenient" I'd understand it,
but surely the tunnel end-points will know whether they are
generating or receiving IPv4 or IPv6 packets?

I also don't understand why it would be considered safe, in the
absence of a header checksum - are you deeming that the tunnel must
have error detection at layer 2?

      Brian

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 11 Dec 2007 16:23:47 -0800

> I don't actually understand the "require". If you'd written "People

Required in the sense if you want to get the protocols into product.

> coding AMT and LISP would find this convenient" I'd understand it,

And it isn't the code, it is the gates.  ;-)

> generating or receiving IPv4 or IPv6 packets?

Yes, but what is your point?

> have error detection at layer 2?

Yes. As well as the low probably of bit-error rates, matching sockets  
and mis-routing, all that would have to work in unison to have a real  
problem.

Dino

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Dec 2007 13:32:43 +1300

On 2007-12-12 13:23, Dino Farinacci wrote:
>>>  encapsulation and sets the UDP checksum field to 0, the IPv6 router 
>>> on the

Oh, you mean required by "fast-cheap-reliable; pick two". Sure.

> And it isn't the code, it is the gates.  ;-)

Just another form of software ;-)

> Yes, but what is your point?

Only that logically, the two cases can be handled differently.
It certainly makes sense that this would be poor engineering.

> and mis-routing, all that would have to work in unison to have a real 

Sure. But don't forget to document that layer 2 error-proofing is needed.

Thanks

     Brian

---

From: <[email-masked]>
Date: Wed, 12 Dec 2007 08:08:28 +0200

Few points on this:
- The issue with having to sum all the data in the packet is moot, since
you do not have to do this with UDP-Lite
- There is no way you can require L2 error detection from all links
between the tunnel endpoints. You can maybe hope. Also L2 errors are not
the only possible source of bit errors.
- For the intended load-balancing effect you should be able to use the
flow label field of the encapsulating IPv6 header. Routers ought to be
able to take that into the hash in addition of the IP addresses.
- If your router can't take the IPv6 flow label into the hash you could
still use multiple addresses per (IPv6) ETR

But I have to agree that I can't see why checksumless IPv6/UDP
encapsulation would be any more dangerous than IPv6 encapsulation
without UDP. But for the purpose being discussed here UDP is really not
needed at all, since you have the flow label in the IPv6 header anyway.

Regards,

	Jarno

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf 
>Of ext Dino Farinacci
>Sent: 12 December, 2007 02:24
>To: Brian E Carpenter
>Cc: Marshall Eubanks; Iljitsch van Beijnum; Stephen Sprunk; 
>Routing Research Group list
>Subject: Re: [RRG] The use of UDP in LISP
>
>>
>>> encapsulation,  it MAY compute a UDP checksum. The IPv6 
>router on the 
>>> other side of the  tunnel receives a UDP checksum of 
>non-zero it MUST 
>>> compute the checksum  according to [UDP-spec]. When an IPv6 router 
>>> uses a UDP header for tunnel  encapsulation and sets the 
>UDP checksum 
>>> field to 0, the IPv6 router on the  other side of the 
>tunnel MUST not 
>>> compute the checksum on the received  packet. This procedure allows 
>>> tunnel routers to behave the same for  tunnel encapsulating 
>IPv4 and 
>>> IPv6 packets.
>Yes. As well as the low probably of bit-error rates, matching 
>sockets and mis-routing, all that would have to work in unison 
>to have a real problem.
>
>Dino
>
>--

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Dec 2007 09:33:10 +1300

Jarno,

However, as you well know, we have very loose semantics for the flow
label still. Admittedly, an encapsulator/decapsulator pair can
agree on their own semantics for the flow label, but it would be
preferable for the encapsulation method to describe flow label
semantics (consistent with RFC 3967).

     Brian

---

From: Lars Eggert <[email-masked]>
Date: Thu, 13 Dec 2007 15:33:45 +0200

On 2007-12-10, at 19:17, ext Dino Farinacci wrote:
>> Could you elaborate a bit, please? It may be the jetlag, but I  
>> can't follow.
>

Thanks for elaborating. Yes, there is some extra work. But assuming  
LISP and other UDP tunnels will limit the UDP-Lite checksum coverage  
to the minimum (i.e., just the header), things become very  
lightweight. (But yes, not as lightweight as not doing any  
checksumming.)

As long as LISP is a research effort, it is very free in following the  
published RFCs. But as soon as we're starting to talk about  
standardization, it is important that LISP follow the RFCs that define  
the behavior of the protocols that it uses. (After all, you'd want  
people to follow the MUST and SHOULDs in any future LISP RFCs, right?)

That pretty much leaves these options on how to go forward:

   * use UDP with checksums
   * use UDP-Lite with minimal checksum coverage
   * push to update RFC2460, then use UDP with no checksums
   * use a different protocol than UDP for tunneling

I have no preference among those four.

Lars

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 13 Dec 2007 10:49:20 -0800

Cross posting to MBONED.

> lightweight. (But yes, not as lightweight as not doing any  

Light weight but not light weight enough. Still a non-starter for  
product development.

> As long as LISP is a research effort, it is very free in following  
> the published RFCs. But as soon as we're starting to talk about  
> standardization, it is important that LISP follow the RFCs that  
> define the behavior of the protocols that it uses. (After all, you'd  
> want people to follow the MUST and SHOULDs in any future LISP RFCs,  
> right?)

And we have to make standards practical for vendors to implement or  
vendors sway from the standard and create defacto standards. Please  
don't take this lightly. This is really important to make protocols  
implementable and not too expensive where non-standard alternatives  
are sought.

The pressing point, as Marshall points out, is AMT. This issue is  
holding AMT from going forward on standards track. We need a  
resolution soon.

>  * use a different protocol than UDP for tunneling

1, 2, and 4 are non-starters. The only option is 3 IMO.

> I have no preference among those four.

That's good. Now who is going to update the spec?

I provided text which Marshall has forwarded, who is going to insert  
it? The IPv6 working group?

Dino

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 13 Dec 2007 14:02:12 -0500

On Dec 13, 2007, at 1:49 PM, Dino Farinacci wrote:

> Cross posting to MBONED.
>
>> Thanks for elaborating. Yes, there is some extra work. But  
>> assuming LISP and other UDP tunnels will limit the UDP-Lite  
>> checksum coverage to the minimum (i.e., just the header), things  
>> become very lightweight. (But yes, not as lightweight as not doing  
>> any checksumming.)
>
>> define the behavior of the protocols that it uses. (After all,  
>> you'd want people to follow the MUST and SHOULDs in any future  
>> LISP RFCs, right?)
>
> I provided text which Marshall has forwarded, who is going to  
> insert it? The IPv6 working
> group?

I think it would be up to us (those who are interested) to prepare a  
new draft (not a bis, but just an addition), and submit it  
(presumably) to IPv6 Maintenance (6man).

I would like to get more input from people making high volume routers  
about these points before that.

Regards
Marshall

---

From: Lars Eggert <[email-masked]>
Date: Fri, 14 Dec 2007 10:05:00 +0200

Hi,

> 1, 2, and 4 are non-starters. The only option is 3 IMO.

I wouldn't want to eliminate 2 or 4 immediately.

IMO, 4 is an option, because UDP was explicitly designed as an end-to- 
end protocol, i.e., not something that routers would need to implement  
on the line card. If I correctly remember the discussions around  
removing the IPv6 checksum and making transport checksums mandatory,  
the desire to remove the IPv6 checksum was exactly to simplify router  
processing, and shift the checksumming burden to the end hosts.

The issue we're running in now is that UDP's apparent attractiveness  
as a router tunneling scheme conflicts with these earlier design  
decisions. The reasons I have heard for why UDP is the right choice  
for this are middlebox traversal and load-balancing. The former  
shouldn't be an issue for LISP, because we're talking about router- 
router tunnels. (AMT may be different.) The second can be achieved  
through other means for another tunneling protocol.

Further, 2 is IMO an option, because I find it personally completely  
acceptable that a major revamp of the routing architecture of the  
Internet will require minor modifications to line cards. I know that  
I'll get strong disagreement for this position, but I always felt that  
the statement that LISP wouldn't require hardware modifications was  
optimistic, and made at a time when the full consequences of the  
proposal weren't understood

> it? The IPv6 working group?

A short draft needs to be written that updates RFC2460, and it will  
need to go through 6man and IESG approval. Your text is a good  
starting point, but the real work will be the consensus building  
required to make it go forward.

Lars

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 14 Dec 2007 11:12:25 +0100

> everyone will configure ITR/ETR's that way.

If the spec mandates that the mapping protocol caries /28 prefixes and  
that ITR round robin flows over the addresses within those /28s, then  
I'm pretty sure ETR operators will do it that way unless this makes  
them so upset they force vendors to make ITRs that don't conform to  
the spec. I.e., laziness then means using the /28.

How about this:

For IPv4 locators there is no checksum issue and we use UDP.

For IPv6 locators there is the checksum issue, the overhead is already  
much larger than with IPv4 but the good parts are that we have the  
flow label and there isn't an ossified installed base yet. So for IPv6  
locators we skip the UDP header.

It's true that there is much discussion on the philosophy of flow  
labels, but as long as there is one, it's stable for the same flow for  
at least a decent amount of time (doesn't have to be forevever,  
changing it at minute scale or longer won't be too problematic for our  
purposes) it's good enough. And since we control the operation of ITRs  
we can mandate that a flow label is present.

And obviously with IPv6 it's trivial to have a larger number of  
addresses per ETR if that's helpful.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 14 Dec 2007 11:12:25 +0100

How about this:

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 14 Dec 2007 23:18:08 +0100

>>       the UDP checksum is not optional.

> it MAY compute a UDP checksum.

> At the least AMT and LISP would require this, and I suspect that  

This doesn't make me very happy. Within the limited scope of LISP it  
could work, but in the more general case it's a trainwreck waiting to  
happen because you can't know in advance if a receiver is going to  
accept the missing checksums. Please see my previous message on the  
subject, I think its pragmatic in both accommodating the desired IPv4  
behavior and retaining compatibility with the IPv6 specs.

By the way: host NICs routinely handle IPv4 IP and TCP/UDP  
checksumming. I suggest router vendors start adding the same logic to  
their hardware, and in a somewhat more general way so that IPv6 can  
also be supported, with additional headers between the IP and TCP/UDP  
headers when present. This will avoid similar issues in the future.

---

From: Tony Li <[email-masked]>
Date: Sat, 15 Dec 2007 09:00:39 -0800

On Dec 14, 2007, at 2:18 PM, Iljitsch van Beijnum wrote:

> checksumming. I suggest router vendors start adding the same logic  
> to their hardware, and in a somewhat more general way so that IPv6  
> can also be supported, with additional headers between the IP and  
> TCP/UDP headers when present. This will avoid similar issues in the  
> future.

Done, circa 1998.

Tony

---

From: Lars Eggert <[email-masked]>
Date: Sun, 16 Dec 2007 10:43:59 +0200

>> TCP/UDP headers when present. This will avoid similar issues in the  

OK, now I'm confused. If router NICs already do checksumming, what is  
the issue?

Lars

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 16 Dec 2007 15:21:14 +0100

> Done, circa 1998.

Must have been while you were away from Cisco, because the IOS  
_software_ that I tested a few years ago wasn't even smart enough to  
filter TCP or UDP with a fragment or AH header in between.

Sigh.

---

From: Tony Li <[email-masked]>
Date: Sun, 16 Dec 2007 11:24:55 -0800

On Dec 16, 2007, at 6:21 AM, Iljitsch van Beijnum wrote:

>>> checksumming. I suggest router vendors start adding the same  
>>> logic to their hardware, and in a somewhat more general way so  
>>> that IPv6 can also be supported, with additional headers between  
>>> the IP and TCP/UDP headers when present. This will avoid similar  
>>> issues in the future.
>
>> Done, circa 1998.
>
> _software_ that I tested a few years ago wasn't even smart enough  
> to filter TCP or UDP with a fragment or AH header in between.
>

Sorry, I should have been more clear.  Basic checksumming has been  
done.  Arbitrary, unspecified complexity doesn't fit well in most  
ASICs.  While there is a proof-of-concept that this can be done, it  
is not the norm, nor would I expect it to become the norm.  The  
market isn't enlightened enough to want it.

Tony