Actually, looking at this as a LISP problem is probalby misleading.
This issue applies to any intermediate device based, high capacity,
tunnel mechanism.
1) High capacity tunnel mechanisms are going to be concerned to
implement in hardware, where the UDP checksum may be difficult
2) High capacity tunnels are the very ones whose traffic could and
should make use of ECMP / LAG operation.
Starting from there, the line of argument then proceeds to look at what
works.
What works in the real world IPv6 deployments is UDP with 0 checksum.
That enables ECMP / LAG without excessive effort / overhead.
Note that UDP-lite is not an answer in terms of what works now. The
vast majority of deployed provider-edge (PE) and provider-core (P)
devices will not look at the port numbers in the UDP-lite header because
they do not recognize the protocol.
The next question is whether this could change. I am still collecting
information on this. Product seems to fall into three categories:
1) Software forwarders. Obviously, these can change
2) Microcoded packet processors - These can probably change which field
is looked at, within limits
3) Hardware mechanisms - these really can not change their handling, as
they are in the field.
Preliminary data indicates that there are a non-trivial number of
hardware devices already out there and handling IPv6.
There are a noticeable number of core devices that could be changed in
small ways (microcoded or software), for example to use the flow-label
instead of some other piece of information in the packet.
We can look at the hardware and complain, or we can look at it and thank
the vendor for acting promptly on RFCs.
We can not reasonably expect the hardware to change in any meaningful
time frame.
I am still colelcting implementation data, so I may be misled by what I
have gotten. But it seems to me that we are unfortunately stuck with
UDP with 0 checksums if we want high capacity tunnels to be able to make
use of ECMP / LAG in the moderate time period (out through at least 5
years, maybe longer.)
Yours,
Joel
Havard Eidnes wrote:
> the O UDP checksum proposal obsoletes all the today deployed nodes
> which check them (so all hosts I know and perhaps a lot of routers too)
OK, so what are the other options for encapsulating a packet in a IPv6
packet?
Um, surely, routers are not specified to validate layer-4
checksums for transit traffic?!?
Let's look at this another way? As I understood it, UDP 0 would
be used by LISP encapsulating/decapsulating devices.
If some random (non-LISP encap/decap) host by mistake received a
0 UDP packet, it would be dropped, which should do no harm.
In practical terms, only LISP encap/decap devices would need to
be modified to accept 0 UDP packets under some specific rule /
circumstance, as an exception to the general rule.
The only thing which would prevent this would be one of
conformance to the letter of the original spec, which apparently
bans 0 UDP checksums.
So what's so bad about that?
Regards,
- Håvard
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
