RE: [MBONED] WGLC for <draft-ietf-mboned-auto-multicast-08.txt> - UDP checksum?

[Dave Thaler <dthaler at windows.microsoft.com>]

Below...

> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund at ericsson.com]
> Sent: Thursday, November 29, 2007 4:53 AM
> To: mboned at ietf.org
> Subject: Re: [MBONED] WGLC for <draft-ietf-mboned-auto-multicast-08.txt> -
> UDP checksum?
>
> Hi,
>
> I was alerted to the discussion on this topic. I do have a few comments
> on the discussion so far:
>
> Dino, the transport checksum is quite important in detecting malfunction
> inside routers and other entities that aren't links that process the
> packet. In those entities the link checksum isn't protecting the packets.
>
> I don't know about any recent investigation on how common these failures
> are. But there is at least this investigation by Stone and Partridge
> published 2000 that shows that this was quite common and because of a
> multitude of different reasons. Please see:
> http://portal.acm.org/citation.cfm?id=347561&dl=GUIDE&dl=ACM
>
> Thus turning off the UDP checksum would mean that the receiver has no
> possibility to verify that the packet was really intended to reach this
> destination.

For IPv4, there is little reason to use a UDP checksum (of non-zero).  AMT is using it as a tunnel, meaning it's a logical layer 2 header.  There is no UDP (or equivalent) checksum in IP-in-IP tunnels, 6to4 tunnels, etc. GRE has an optional checksum.  If you needed one in AMT, then you'd have to argue you needed one for all the others.

Since the UDP destination is acting as a router, it decapsulates the packet and forwards it, and the final destination of the embedded packet is all that needs to be delivered to the correct place.  The final destination doesn't care which router decapsulated it any more than it cares which router forwarded a non-encapsulated packet to it.  If the decapsulator is incorrect, it will either drop or forward the packet.  If it drops, that's the same as having a checksum.  If it forwards, that's perfectly fine.

> For IPv6 you even don't get the choice. Please consider what will happen
> at the reception of your IPv6/UDP packet with UDP checksum field = 0
> according to section 8.1 of RFC 2460:
>
>       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.
>
> It will be discarded. It may in fact be discarded en-route also if some
> node decides to verify the checksum. I don't find at all okay to
> disregard to such fundamental processing rules of basic internet
> protocol stacks.

As Dino notes, a checksum of 0 is allowed in RFC 768, so no change to UDP per se is needed.  However it is true that in IPv6 you don't get a choice.  Section 6.6 should say it needs to be valid for IPv6 unless RFC 2460 is updated.

> Based on the glance of the AMT spec I took you need to have port numbers
> in the gateway. Thus the two possible choices as I see it are:
>
> 1. Use UDP and bite the bullet in having to compute the checksum
>
> 2. Use UDP-Lite and likely have failures if there is NAT between the
> tunnel ingress and the AMT gateway.

As Pekka stated, UDP-Lite doesn't go through most NATs and hence is a non-starter.

> I think this is a choice your poison situation.
>
> I also have two WG last call comment myself.
>
> A. This specification needs to discuss MTU issues with the data tunneling.

Agree.

> B. Possible fragmentation issues with AMT messages. What are the largest
> payloads you can put into the signalling messages.

Same as the data messages, i.e., it's based on the MTU of the tunnel, since the payload is an IP packet (containing an IGMP/MLD message in the signaling messages).

> Is it at all intended that AMT should work with the AMT gateway behind a
> NAT?

Yes.

-Dave

> Cheers
>
> Magnus Westerlund
>
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com
> ----------------------------------------------------------------------
>
>
> _______________________________________________
> MBONED mailing list
> MBONED at ietf.org
> https://www1.ietf.org/mailman/listinfo/mboned



_______________________________________________
MBONED mailing list
MBONED at ietf.org
https://www1.ietf.org/mailman/listinfo/mboned