RE: [MBONED] APPSDIR review of draft-ietf-mboned-64-multicast-address-format-01

[<[e-mail]>]

Dear Cartsen,

The algorithm to extract the embedded IPv4 address is as follows: 

If the multicast address belongs to ff3x:0:8000/33 or ffxx:8000/17, extract the last 32 bits of the IPv6 address.

Are you suggesting to add such clarification to the address format I-D?

Cheers,
Med 

>-----Message d'origine-----
>De : Carsten Bormann [mailto:[e-mail]] 
>Envoyé : jeudi 10 mai 2012 13:01
>À : Tina TSOU
>Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; [e-mail]; 
>[e-mail]; The IESG; [e-mail] 
>application-layer protocols; 
>[e-mail]
>Objet : Re: [MBONED] APPSDIR review of 
>draft-ietf-mboned-64-multicast-address-format-01
>
>Hi Tina,
>
>thanks for the pointers.
>
>On the problem statement, you say:
>
>> It's has been adopted as MBONED WG item. The authors will 
>submit the WG draft soon.
>
>So I would normally expect the two documents (problem 
>statement and normative spec) to go through as a cluster (if 
>not the problem statement first).
>Given the difference in advancement, that may be difficult to 
>achieve, though; if that is not possible, the spec will need 
>to provide some context by itself.
>
>> 
>http://datatracker.ietf.org/doc/draft-perreault-mboned-igmp-mld
>-translation/
>
>This document reveals that the IPv4 multicast address embedded 
>into the IPv6 multicast address is indeed used as such by 
>applications on the other side of the mapper (5.2.4).
>My main comment is that the mboned-64-multicast-address-format 
>document does not even hint that this might be the case, much 
>less defines semantics that might be used by an application on 
>the IPv6 side (and there have been other comments that 
>applications are not even involved on the IPv6 side, which 
>doesn't quite seem to mesh with this document).
>
>> http://datatracker.ietf.org/doc/draft-taylor-pim-v4v6-translation/
>
>The latter is very clear in saying
>
>   If an IPv6
>   group address to be translated matches the format specified in that
>   document for an IPv4-embedded IPv6 ASM or SSM group address, the
>   corresponding IPv4 group address MUST be obtained by extracting the
>   low-order 32 bits from the IPv6 address.  (The value of the sub-
>   group-id field is irrelevant to this procedure.) 
>
>So that supports my conjecture that the following is a strong, 
>unstated requirement on the format document:
>It MUST be possible to determine, by looking at a packet, 
>whether the destination IP address in there is matching the 
>format or not.
>
>This places an even stronger burden on the completeness of the 
>specification than I initially thought.
>
>I would address this by describing the algorithm that gets 
>used to determine whether there is a match by looking at the packet.
>(The fact that I cannot determine this algorithm even by 
>educated guessing is my other main comment.)
>
>Grüße, Carsten
>
>