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:c...@tzi.org] >Envoyé : jeudi 10 mai 2012 13:01 >À : Tina TSOU >Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; mbo...@ietf.org; >6...@ietf.org; The IESG; apps-disc...@ietf.org >application-layer protocols; >draft-ietf-mboned-64-multicast-address-format....@tools.ietf.org >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 > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
