Subject: Re: [MBONED] draft-ietf-mboned-auto-multicast-12 - Transport comments

From: Greg Bumgardner <[email-masked]>
Date: Thu, 12 Apr 2012 11:55:41 -0700

Gorry,

Comments below...

-g.b.

On 3/29/12 10:50 AM, Gorry Fairhurst wrote:
>
> Here is my review of draft-ietf-mboned-auto-multicast-12 from a 
> transport perspective. with some questions/comments.
>
> best wishes
>
> Gorry
>
> #### UDP Encapsulation
> 4.2.2.3.
>    To avoid placing an undue burden on the relay platform, the protocol
>    specifically allows zero-valued UDP checksums on the multicast data
>    messages.  This is not an issue in UDP over IPv4 as the UDP checksum
>    field may be set to zero.  However, this is a problem for UDP over
>    IPv6 as that protocol requires a valid, non-zero checksum in UDP
>    datagrams [RFC2460].  Messages sent over IPv6 with a UDP checksum of
>    zero may fail to reach the gateway.  This is a well known issue for
>    UDP-based tunneling protocols.  See [I-D.ietf-6man-udpchecksums] and
>    [I-D.ietf-6man-udpzero] for details.
>
> - I think this needs to also explicitly say that since AMT is a tunnel 
> the methods defined in [I-D.ietf-6man-udpchecksums] MAY be used.
>
Done.
> #### Reception
> I think it is wise to note:
>
> The receiver MUST allow UDP datagrams with a checksum, even when it is 
> known the sender originates UDP datagrams with a zero checksum.
>
> - This the case when the sender inserts a UDP checksum of zero, a non 
> zero UDP checksum may be received. Such a UDP checksum may for example 
> be generated by checksum-offloading at a lower layer, or by a IPv4 
> NAPT, 6-4 NAT, or a middlebox.
>
Yes.
> #### Blackholes when middleboxes/receivers drop IPv6 datagrams with 
> zero UDP checksum.
>
> - I think slightly more needs to be said about how to verify the path 
> operation (especially in the presence of middleboxes). Is it intended to
> periodically sends UDP packets with a computed checksum to provide 
> some form of loss detection - since at the moment I don't see there is 
> any real way to know that traffic with a zero checksum is being 
> dropped, e.g. due to routing via a different middlebox that drops zero 
> checksum UDP datagrams using IPv6.
>
It would be nice to provide some sort of keep-alive/beacon function that 
might be used to detect loss of the multicast data messages, but I think 
we'll have to treat this topic as out-of-scope for the AMT spec at this 
point.

I can add some informative text that addresses this topic in the 
implementation considerations section. Applications might use a 
well-known multicast beacon to detect loss. I suppose relays might 
provide this function by broadcasting UDP datagrams to a specific, 
well-known group address.
> - At least it would be good to explain and refer to 
> I-D.ietf-6man-udpzero, so that people know to be aware of the 
> "blackhole" for the potential data plane.
>
> #### Fragmentation
>
>    Applications that use AMT to join
>    multicast UDP streams may also need to perform IP reassembly to
>    reconstruct UDP datagrams that were fragmented prior to replication
>    and encapsulation in the relay.
>
> - UDP fragmentation is fine when there is a checksum for the UDP 
> header, but for IPv6 this is not good, and wuld go against best 
> practce [I-D.ietf-6man-udpzero].
>
My intent was to indicate that fragmentation may occur as a result of 
encapsulation and that receivers may need to reassemble these fragments 
to obtain the original content. I was primarily considering the 
application-as-gateway use-case for AMT.

I'll take a look at the 6man doc and rework as necessary.
> #### Router Alert
>
> The draft speaks about IP encapsulation of membership reports etc, 
> which would normally carry the IP Router Alert option. What is the 
> expectation here?
> - Is an IP packet with an RA option discarded?
> - IS an IP packet with a RA option accepted?
>
I think you asked this in the earlier e-mail. The IGMP/MLD protocol 
implementation provided by a gateway or relay is expected to provide 
necessary handling of IGMP/MLD protocol messages, including validity 
checks, such as the presence of the router alert. The AMT spec simply 
adopts the requirements described by those RFCs.
>
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned
>