Thanks,
As promised in 6man, I'll make a longer email on why I think setting the
IPv6 UDP Checksum to zero is *not* the same as for IPv4 and what the
implications are. We touched on this briefly in TSV today, but I'd like
to take a little time to check the arguments - it seems there are many
views here and it would be good to get to the bottom of this.
A few other comments in-line,
Gorry
Gorry Fairhurst wrote:
On Jul 29, 2009, at 8:02 AM, Dino Farinacci wrote:
>> >> This is a reminder that draft-fairhurst-6man-tsvwg-udptt and
>> >>
>> >> http://tools.ietf.org/html/draft-eubanks-chimento-6man-00
>> >>
>> >> are still open and will be discussed at the 6man meeting Wednesday.
>> >>
>> >> Basically, one prescribes no checksum for the "outer" packet in
>> >> IPv6 encapsulations, the other a fixed checksum per flow. My
>> >> understanding is that this matter is relevant to LISP.
>> >>
>> >> If you are interested, please try to attend as a decision may be
>> >> made soon.
> >
> > Sorry, I have a conflict right now. But here is the position of one
> > LISP implementor and a coauthor of the LISP specifications:
> >
> > From a practical perspective, we prefer that a LISP encapsulator
> > (ITR and PTR) not incurred additional work when encapsulating
> > packets. The main LISP spec indicates:
> >
> > (1) The UDP checksum in the outer header MUST be set to 0 by an
> > encapsulator.
> > (2) The decapsulator MUST ignore the UDP checksum.
> >
> > We stand by this text and see no reason to change it.
Are you using "we" to refer to yourself as both an implementor and a
co-author? ;-)
FWIW, I have serious concerns about draft-fairhurst-6man-tsvwg-udptt,
as it involves overloading the UDP "next-header" value to refer to two
different header types (real UDP and UDP-TT).
One thing that was discussed in 6man was why thsi was different to
UDP-Lite (which needed a separate protocol number), for the record there
were two important differences here:
1) UDP-Lite implies very different semantics for the payload - i.e.
error-tolerant data. Con fusing this with UDP data would not be good.
2) UDP-Lite needs to signal the link-driver that it is a UDP-Lite packet
to atke advantage of the partial coverage feature. The header value
currently provides this way.
I do however, suggest we discuss this after discussing the UDP checksum
issue. I'd be most happy to withdraw my draft if the decision is to
preserve standard IPv6 UDP Checksum behaviour.
However, I also have serious concerns about using zero UDP checksums
with IPv6.
> >
> > There are no practical reasons to use outer header UDP checksums
> > regardless of the 4 combinations of packet types (v4-in-v4, v6-in-
> > v6, v6-in-v4, or v4-or-v6) being forwarded by LISP routers.
I think that this statement is answering the wrong question...
Since we have standards-track protocols that indicate that UDP
checksums must not be zero in IPv6 (for good reasons), I believe that
we should use valid UDP checksums in IPv6 outer headers, unless we can
provide practical (and compelling) reasons why _not_ to do so. So,
what are those reasons?
If we do manage to achieve consensus that it makes sense to zero-out
the UDP checksum in IPv6 outer headers, there are a number of
questions we will have to answer...
The problem with eliminating the UDP checksum in UDP over IPv6 is that
(unlike in IPv4) the IPv6 source and destination addresses are not
protected. So, the packet may be corrupted such that it is sent to
the wrong destination. When it arrives at the wrong destination, it
may be processed by an IP stack that is unaware of LISP.
Agreed.
We need to consider what will happen if one of these packets is
received by a non-LISP node. Are you assuming that non-LISP stacks
will simply throw away these packets, because they have zero (and
therefore invalid) UDP checksums? That's only a good assumption if we
assume that LISP is the _only_ protocol that will allow the use of
zero checksums. If the packet is processed by the stack, there
shouldn't be a non-LISP application on port 4342, so the packet should
be dropped. We should define, however, how the sending LISP node will
deal with an ICMPv6 "port unreachable" error, so that an error
received from the wrong destination does not interfere with
communication with the right destination.
I suggest LISP is unlikely to be the only application to use this. AMT
has already suggested a use in hosts. I suggest there will be others,
especially once this is in the end-stack.
We also need to consider the possibility that a packet will be
received by a different LISP node than the one for which it was
intended, or that it will arrive at the correct LISP destination with
the wrong source address in the external header. What happens in
those cases?
Margaret
I'd be keen to continue this later (sorry, but I will be disappearing
from email for the next week after the IETF).
best wishes,
Gorry
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
