On Thu, Jul 30, 2009 at 12:49 PM, Margaret Wasserman<m...@lilacglade.org> wrote: > > > 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
(enumerate good reasons pls) > 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... I thought the question was actually to: o drop no-checksum packets at transition points (v4 -> v6) or o compute checksums at transition points I don't think there was discussion about not checksumming ipv6 packets, changing the v6 spec to look more like its predecessor here isn't a bad thing (I think)... but wasn't part of the original discussion. > 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. huh? doesn't this mythical distant system have a network stack with state for UDP packets and isn't it going to just reject the packet with an icmp port-unreachable? (as happens today on all os's I've seen) > > 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 some list originating node will get a spurious icmp port unreachable. > > 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? lisp, I think, has nonce protections (or application layer protections) for this sort of mishap, it has to in order to deal with normal security issues. -chris -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
