Subject: APPSDIR review of draft-ietf-mboned-64-multicast-address-format-01

From: Carsten Bormann <[email-masked]>
Date: Sun, 6 May 2012 22:57:38 +0200

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Grüße, Carsten
---------------------------------

Document: draft-ietf-mboned-64-multicast-address-format-01
Title: IPv4-Embedded IPv6 Multicast Address Format
Reviewer: Carsten Bormann
Review Date: 2012-05-06
IETF Last Call Date: 2012-04-19

** Summary: This draft is NOT ready for publication as a Proposed
Standard and should be revised before publication.

The document appears as an attempt to extend the reasoning of RFC 6052
to multicast IPv4 addresses.  However, while unicast IPv4 addresses
and their IPv6 counterparts are assigned as part of network
configuration, multicast addresses are decided upon by applications.
The document is very short on information how an application should
decide when to make use of the newly defined formats.  It is therefore
also hard to understand why these formats are needed in the first
place.  There appears to be a transition model in the minds of the
authors that makes this necessary or practical, and this information
must be made part of the document for it to be useful.

** Major Issues:

To continue the summary: I don't understand which network elements
need to be able to determine, by looking at an IP address, that this
document is in use.  What for?  More generally, which entities need to
interoperate based on a common understanding of this format?

Of the various fields left "configurable according to local policies
of the entity managing the IPv4-IPv6 Interconnection Function", which
are important for applications?  How do they know these policies?  If
that information is all in the two parameters "ASM_MPREFIX64" and
"SSM_MPREFIX64", what is the protocol that will be used to make this
information available to applications?  I don't think this can be a
standards-track document without defining at least one MTI protocol
for disseminating this information.  What is an implementation
supposed to do that receives an address that looks like it is governed
by this document but does not conform to either of the agreed
prefixes disseminated to the implementation?

This document needs editorial attention.  I will abstain from trying
to make detailed corrections, as this would become tedious quickly.
While much of this work could be done by the RFC editor, some of the
editorial decisions will enter e.g. IANA registries, so the technical
terms need to be decided now.  More importantly, understanding this
document during its development process (including mine as a reviewer)
may be hampered by its editorial shortcomings.

** Minor Issues:

My first editorial problem is with the title.  This address format is
not embedded in IPv4, as the title wants to make us believe.  Instead,
it is talking about an multicast address format for IPv6 that embeds
an IPv4 multicast address.  (While this misleading naming repeats the
same mistake that has been made in RFC 6052, at least there it is not
part of the title.)

3

The role of 64IX is very unclear.  My conjecture is that this draft is
defining the address format for the case M=1 only (i.e., address[16] =
1).  No text defines what happens for M=0, so the assumption appears
to be that RFC 4291 applies unchanged in this case.  If this
conjecture is correct, this needs to be made much clearer.

What is "r"?  Define.

4

Why is 64IX moving around here?
(The discriminating bit M now seems to be address[32].)
How does one find out which of the two positions of the M bit to use?

.          o  sub-group-id: The default value is all zeros.
How does an application find out when to choose a different one?

.             232.0.0.1-232.0.0.255 range is being
.             reserved to IANA.
Who is making this reservation?  ("is being reserved" means the
resernation is going on right now, but I don't find anything in 9.)

7

7 seems to imply this format is only useful where RFC 6052 is in use.
If this is true, this should be clearly stated.  More specifically,
the assumption appears to be that all nodes that need to exchange
information that concerns IPv4 sources need to have the same RFC 6052
parameters in effect.  How is that ensured?

** Nits:

10 -- s/defined/defines/

(And many more, see above.)

---

From: <[email-masked]>
Date: Wed, 9 May 2012 15:09:25 +0200

Dear Carsten,

Thank you for the review. 

Please see inline.

Cheers,
Med 

>-----Message d'origine-----
>De : Carsten Bormann [mailto:[email-masked]] 
>Envoyé : dimanche 6 mai 2012 22:58
>À : 
>[email-masked]
>g; [email-masked] application-layer protocols
>Cc : The IESG; [email-masked]; [email-masked]
>Objet : APPSDIR review of 
>draft-ietf-mboned-64-multicast-address-format-01
>

Med: There are plenty of applications using this address format: e.g., [I-D.ietf-softwire-mesh-multicast], [I-D.ietf-softwire-dslite-multicast], [I-D.ietf-softwire-multicast-prefix-option], [I-D.venaas-behave-v4v6mc-framework],  [I-D.sarikaya-behave-netext-nat64-pmip], [I-D.sarikaya-behave-mext-nat64-dsmip], etc. We had pointers to some of those drafts in earlier versions of the document but we removed them and adopted the same approach as RFC6052: only the address format is defined while the usage is defined in companion documents. More details are also documented here: http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-format-03#appendix-A.1 and http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-format-03#appendix-A.2. 

There is also a problem statement, available at: http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-03 which can be cited in the introduction. 

>interoperate based on a common understanding of this format?

Med: Elements which make use of the address format are deployment-specific; this can be a receiver, an IPv4-IPv6 PIM interworking function, IGMP/MLD Interworking function. We didn't quoted these interworking functions because this is deployment-specific. Do you think your issue can be solved if we add a pointer to one of the solutions documented listed above?  

>are important for applications?  How do they know these policies?

Med: The content of this filed is left configurable. Its value will depend on the policies enforced by the administrative entity. Examples of these policies are: embedded-RF, use unicast-based prefix, etc. Applications are not aware of these policies since a prefix will (likely /96) will be provisioned (see Section 6).

  If
>for disseminating this information.

Med: The provisioning of the ASM_PREFIX64 and the SSM_PREFIX is orthogonal to the address format itself. Various methods can be used but this is out of scope of the document. We can add a pointer to http://tools.ietf.org/html/draft-ietf-softwire-multicast-prefix-option-00 as a provisioning example. Would you be fine with adding such reference?

  What is an implementation
>prefixes disseminated to the implementation?

Med: This is an issue for the provisioning method and not for the specification of the address format itself.

>same mistake that has been made in RFC 6052, at least there it is not

Med: Could you please suggest a better title? 

>conjecture is correct, this needs to be made much clearer.

Med: The current text says: "When "M-bit" is set to 1, it indicates that a multicast
      IPv4 address is embedded in the low-order 32 bits of the multicast
      IPv6 address.". I can add: "When "M-bit" is set to 0, the address format follows [RFC4291].". Would this be fine with you? 

>What is "r"?  Define.

Med: This means "reserved". The text says: "All the remaining bits are reserved and MUST be set
      to 0.". Do you think the text should be clarified further? 

>How does one find out which of the two positions of the M bit to use?

Med: Once the prefix is configured to a receiver, an IPv4-IPv6 PIM interworking function, the question of the location of the M-bit is not relevant anymore. If both ASM and SSM modes are supported, two prefixes will be used. 

>How does an application find out when to choose a different one?

Med: Applications are provisioned with the full prefix; see Section 6.

>resernation is going on right now, but I don't find anything in 9.)

Med: We removed that sentence as a result of a comment I received from SM (see mboned archives).

>parameters in effect.  How is that ensured?

Med: This is a generic issue for RFC6052. We can document the issue if it is specific to the multicast context. 

>10 -- s/defined/defines/

Med: Fixed. Thanks.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 9 May 2012 20:20:35 +0200

Hi Med,

thanks for looking into my review.  Let me take this opportunity to reiterate that, while I wrote this review for the Applications Area Directorate, it is not intended to bear more weight than any other comment submitted by an individual during a Last Call.

> Med: There are plenty of applications using this address format: e.g., [I-D.ietf-softwire-mesh-multicast], [I-D.ietf-softwire-dslite-multicast], [I-D.ietf-softwire-multicast-prefix-option], [I-D.venaas-behave-v4v6mc-framework],  [I-D.sarikaya-behave-netext-nat64-pmip], [I-D.sarikaya-behave-mext-nat64-dsmip], etc. We had pointers to some of those drafts in earlier versions of the document but we removed them and adopted the same approach as RFC6052: only the address format is defined while the usage is defined in companion documents.

The problem with this is that you now have a bit allocation without any semantics.
What is different, then, from any other way to allocate multicast addresses?
If you want this part of the address space to have some specific semantics, you have to give it some.

> More details are also documented here: http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-format-03#appendix-A.1 and http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-format-03#appendix-A.2. 
> 

I do believe that there needs to be some indication in the document.
Maybe some of the material from the problem statement can be put into an appendix.
BTW, what is the plan with the problem statement document?  Was this too contentious to make it a WG document?

> Med: Elements which make use of the address format are deployment-specific; this can be a receiver, an IPv4-IPv6 PIM interworking function, IGMP/MLD Interworking function. We didn't quoted these in…

So the idea is that this is a common format that can be used by any number of transition mechanisms?
How do you avoid the mechanisms getting confused (e.g., one mechanism allocating an address that is then processed incorrectly by a network element that is using another mechanism)?

Yes, I think standardizing this document in a cluster with one or more transition mechanism documents and adding mutual references would be the best way to handle this.  As long as the question above has a good answer...

> Med: The provisioning of the ASM_PREFIX64 and the SSM_PREFIX is orthogonal to the address format itself. Various methods can be used but this is out of scope of the document. We can add a pointer t…

Are there any requirements on the provisioning mechanism to maintain the integrity of the semantics you desire?
I think the format just needs to state those.
Pointing to a protocol as an existence proof would also be an improvement.

> Med: This is an issue for the provisioning method and not for the specification of the address format itself.

I'm not sure about that.  If I get a conflicting address using some control protocol, should I deny that?  Just go ahead anyway?
Will this confuse the network elements performing the transition mechanisms?
(My questions may sound very theoretic, but that is because the draft just doesn't tell me enough to even know whether these are good questions.)

> Med: Could you please suggest a better title? 

Well, given that RFC 6052 already uses "IPv4-embedded" in what I read as the inverted semantics, this naming is hard to fix.
But maybe

	IPv6 Multicast Address Format With Embedded IPv4 Multicast Address 

is not too long and much less ambiguous.

>      IPv6 address.". I can add: "When "M-bit" is set to 0, the address format follows [RFC4291].". Would this be fine with you? 

Yes, maybe make even more explicit that this document just governs those addresses where the M bit is set to 1.

>      to 0.". Do you think the text should be clarified further? 

Yes.  I think you should not talk about a "64IX" nibble at all (which then requires you to reserve three of those four bits) but just talk about the one M bit that you are assigning semantics to.

> Med: Once the prefix is configured to a receiver, an IPv4-IPv6 PIM interworking function, the question of the location of the M-bit is not relevant anymore. If both ASM and SSM modes are supported,…

Again, that is true if all network elements agree on the provisioned prefixes.
But if they do, what is the point of this document?
Just saying "transition mechanisms can allocate a 96-bit prefix to which a 32-bit IPv4 multicast address is appended" would be enough then, no?

I get the idea that people want to write code that looks at this bit and exhibits different behavior based on whether it is set or not.
If that is not the case, there is no need for that bit...

> Med: Applications are provisioned with the full prefix; see Section 6.

But what does "default value" mean then?  Who is doing the defaulting, and what does it mean to use the default or to not use it?

> Med: We removed that sentence as a result of a comment I received from SM (see mboned archives).

Fine.

> Med: This is a generic issue for RFC6052. We can document the issue if it is specific to the multicast context. 

I actually think it is more interesting in the multicast case, because multicast can span multiple domains (where a unicast address is assigned to one node that is "in" a specific domain).

Grüße, Carsten

---

From: Tina TSOU <[email-masked]>
Date: Wed, 9 May 2012 22:44:30 +0000

Sent from my iPad

> BTW, what is the plan with the problem statement document?  Was this too contentious to make it a WG document?
It's has been adopted as MBONED WG item. The authors will submit the WG draft soon.
> Yes, I think standardizing this document in a cluster with one or more transition mechanism documents and adding mutual references would be the best way to handle this.  As long as the question abo…
http://datatracker.ietf.org/doc/draft-perreault-mboned-igmp-mld-translation/
http://datatracker.ietf.org/doc/draft-taylor-pim-v4v6-translation/
> Pointing to a protocol as an existence proof would also be an improvement.
Good suggestion.
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 10 May 2012 02:52:10 +0000

Hi Carsten,

Thanks very much for reviewing the document. I just want to add a point to
your question about how applications decide when to use this multicast
address format. In fact, they don't. Imagine a use case where a legacy
IPv4 IP-TV receiver (an app) wants to join a channel which is broadcasted
in IPv6. The app will continue to send the igmp-join (say 224.1.2.3).
There will be a function in the network which is statically configured
that when it receives a igmp-join, it would covert to a corresponding
mld-join. The IPv6 address in the join message will follow what is
described in this draft. This Adaptive Function is transparent to the
application and managed by the network.

Thanks,
Yiu

---

From: Jacni Qin <[email-masked]>
Date: Thu, 10 May 2012 14:20:48 +0800

Hi Carsten,

Thanks a lot for your comments, please see inline below.

> If you want this part of the address space to have some specific semantics, you have to give it some.
For the semantics, you can see YIu's point. More specifically, for 
example, some adaptive/interworking function of network elements can 
interpret it as, if the M bit is set 1, then pick the corresponding IPv4 
group address.

> How do you avoid the mechanisms getting confused (e.g., one mechanism allocating an address that is then processed incorrectly by a network element that is using another mechanism)?
Not sure whether I understand your question here correctly, but let me 
try to,
The address/prefix allocating should be an independent component of the 
service provisioning, and should just make a consistent assignment of 
the block throughout the related elements. The format standardized is 
for the elements to perform the adaptive function without any coordination.

> I think the format just needs to state those.
I guess standardizing the format is to maintain the integrity of the 
semantics. For the responsibility of address/prefix provisioning 
mechanism, please see my response above.
Or maybe I misunderstand your question?

> Will this confuse the network elements performing the transition mechanisms?
It should be in the scope of operations or deployment, to avoid that.

> is not too long and much less ambiguous.
We'll consider it, thanks a lot.

> Just saying "transition mechanisms can allocate a 96-bit prefix to which a 32-bit IPv4 multicast address is appended" would be enough then, no?
In this way, the elements have to maintain "states", and coordination is 
required. Even though, they also have to be told how to derive the IPv4 
multicast address embedded.

> But what does "default value" mean then?  Who is doing the defaulting, and what does it mean to use the default or to not use it?
It can mean, for example "if RFC3956, embedding RP in an IPv6 multicast 
address is not used".

Cheers,
Jacni

---

From: <[email-masked]>
Date: Thu, 10 May 2012 11:11:58 +0200

Dear Carsten,

Please see inline. 

Cheers,
Med 

>Envoyé : mercredi 9 mai 2012 20:21
>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : 
>g; [email-masked] application-layer protocols; The 
>IESG; [email-masked]; [email-masked]
>Objet : Re: APPSDIR review of 
>thanks for looking into my review.  Let me take this 
>opportunity to reiterate that, while I wrote this review for 
>the Applications Area Directorate, it is not intended to bear 
>more weight than any other comment submitted by an individual 
>during a Last Call.
>
>> Med: There are plenty of applications using this address 
>format: e.g., [I-D.ietf-softwire-mesh-multicast], 
>[I-D.ietf-softwire-dslite-multicast], 
>[I-D.ietf-softwire-multicast-prefix-option], 
>[I-D.venaas-behave-v4v6mc-framework],  
>[I-D.sarikaya-behave-netext-nat64-pmip], 
>[I-D.sarikaya-behave-mext-nat64-dsmip], etc. We had pointers 
>to some of those drafts in earlier versions of the document 
>but we removed them and adopted the same approach as RFC6052: 
>only the address format is defined while the usage is defined 
>in companion documents.
>
>If you want this part of the address space to have some 
>specific semantics, you have to give it some.

Med: Ok. I'm planning to do these changes:

(a) Re-insert this appendix: http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-format-03#appendix-A.2 and a reference to it in the introduction?

(b) Add this text to the introduction:

   Recently various solutions (e.g., [I-D.venaas-behave-v4v6mc-framework],
   [I-D.ietf-softwire-mesh-multicast] or [I-D.ietf-softwire-dslite-multicast]) have been proposed to allow
   access to IPv4 multicast content from hosts attached to IPv6-enabled
   domains.

   Even if these solutions have distinct applicability scopes
   (translation vs. encapsulation) and target different use cases, they
   all make use of specific IPv6 multicast addresses to embed an IPv4
   multicast address.  Particularly, the IPv4-embedded IPv6 multicast
   address is used as a destination IPv6 address of multicast flows
   received from an IPv4-enabled domain and injected by the IPv4-IPv6
   Interconnection Function into an IPv6-enabled domain.  It is also
   used to build an IPv6 multicast state (*, G6) or (S6, G6)
   corresponding to their (*, G4) or (S4, G4) IPv4 counter parts by the
   IPv4-IPv6 Interconnection Function.

Are you OK with these proposed changes?

>
>> More details are also documented here: 
>http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-
>address-format-03#appendix-A.1 and 
>http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-
>address-format-03#appendix-A.2. 
>> 
>> There is also a problem statement, available at: 
>http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-03
> which can be cited in the introduction. 
>
>BTW, what is the plan with the problem statement document?  
>Was this too contentious to make it a WG document?

Med: The problem statement document has been adopted as an mboned WG document. I added this sentence:

   More discussion about issues related to IPv4/IPv6 multicast can be
   found at [I-D.jaclee-behave-v4v6-mcast-ps].

>> Med: Elements which make use of the address format are 
>deployment-specific; this can be a receiver, an IPv4-IPv6 PIM 
>interworking function, IGMP/MLD Interworking function. We 
>didn't quoted these interworking functions because this is 
>deployment-specific. Do you think your issue can be solved if 
>we add a pointer to one of the solutions documented listed above?
>
>How do you avoid the mechanisms getting confused (e.g., one 
>mechanism allocating an address that is then processed 
>incorrectly by a network element that is using another mechanism)?

Med: What do you think is needed to be added to http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-01#section-6? Thanks.

>
>Yes, I think standardizing this document in a cluster with one 
>or more transition mechanism documents and adding mutual 
>references would be the best way to handle this.  As long as 
>the question above has a good answer...
>
>> Med: The content of this filed is left configurable. Its 
>value will depend on the policies enforced by the 
>administrative entity. Examples of these policies are: 
>embedded-RF, use unicast-based prefix, etc. Applications are 
>not aware of these policies since a prefix will (likely /96) 
>will be provisioned (see Section 6).
>> 
>>  If
>> Med: The provisioning of the ASM_PREFIX64 and the SSM_PREFIX 
>is orthogonal to the address format itself. Various methods 
>can be used but this is out of scope of the document. We can 
>add a pointer to 
>http://tools.ietf.org/html/draft-ietf-softwire-multicast-prefix
>-option-00 as a provisioning example. Would you be fine with 
>adding such reference?
>
>Are there any requirements on the provisioning mechanism to 
>maintain the integrity of the semantics you desire?

Med: The provisioning mechanism (e.g., dhcp, netconf, etc.) is not "aware" of the semantic. There are no specific requirements compared to another provisioning context. If your comment is related to http://tools.ietf.org/html/rfc6052#section-5.2, this is already captured in the Security Considerations section.

>Pointing to a protocol as an existence proof would also be an 

Med: I added a I-D.ietf-softwire-multicast-prefix-option as an informative reference.

>> Med: This is an issue for the provisioning method and not 
>for the specification of the address format itself.
>
>I'm not sure about that.  If I get a conflicting address using 
>some control protocol, should I deny that?  Just go ahead anyway?

Med: The current text says that up to 2 MPREFIX64 can be provisioned; one prefix for ASM and another one for SSM. Just like any other configurable parameter, the value of these parameters will be set to the latest (valid) enforced configuration. I still don't see what I can add to Section 6. 

>(My questions may sound very theoretic, but that is because 
>the draft just doesn't tell me enough to even know whether 
>these are good questions.)
>
>Well, given that RFC 6052 already uses "IPv4-embedded" in what 
>I read as the inverted semantics, this naming is hard to fix.
>But maybe
>

Med: Thanks. I updated the text.

>>      IPv6 address.". I can add: "When "M-bit" is set to 0, 
>the address format follows [RFC4291].". Would this be fine with you? 
>
>Yes, maybe make even more explicit that this document just 
>governs those addresses where the M bit is set to 1.
>
>>> What is "r"?  Define.
>> 
>> Med: This means "reserved". The text says: "All the 
>remaining bits are reserved and MUST be set
>Yes.  I think you should not talk about a "64IX" nibble at all 
>(which then requires you to reserve three of those four bits) 
>but just talk about the one M bit that you are assigning semantics to.
>
>>> 4
>>> 
>> Med: Once the prefix is configured to a receiver, an 
>IPv4-IPv6 PIM interworking function, the question of the 
>location of the M-bit is not relevant anymore. If both ASM and 
>SSM modes are supported, two prefixes will be used. 
>
>Just saying "transition mechanisms can allocate a 96-bit 
>prefix to which a 32-bit IPv4 multicast address is appended" 
>would be enough then, no?
>
>I get the idea that people want to write code that looks at 
>this bit and exhibits different behavior based on whether it 
>is set or not.
>But what does "default value" mean then?  Who is doing the 
>defaulting, and what does it mean to use the default or to not use it?

Med: The entity managing the IPv4/IPv6 Interconnection function.

>> Med: This is a generic issue for RFC6052. We can document 
>the issue if it is specific to the multicast context. 
>
>I actually think it is more interesting in the multicast case, 
>because multicast can span multiple domains (where a unicast 
>address is assigned to one node that is "in" a specific domain).
>

Med: Yes, but still this is a generic issue for RFC6052. Some deployment-specific documents already covered this point: e.g., http://tools.ietf.org/html/draft-ietf-softwire-dslite-multicast-02#section-5: 

"The mAFTR and mB4 MUST use the
   same mPrefix64 and uPrefix64, as well as run the same algorithm for 
   building IPv4-embedded IPv6 addresses."

Do you want to see a similar wording in the address format draft?

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 May 2012 13:00:45 +0200

Hi Tina,

thanks for the pointers.

> 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

---

From: <[email-masked]>
Date: Thu, 10 May 2012 14:09:17 +0200

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 

>Envoyé : jeudi 10 mai 2012 13:01
>À : Tina TSOU
>Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]; 
>[email-masked]; The IESG; [email-masked] 
>application-layer protocols; 
>[email-masked]
>Objet : Re: [MBONED] APPSDIR review of 
>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.
>
>> 
>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).
>
>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.
>
>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
>
>

---

From: Brian Haberman <[email-masked]>
Date: Thu, 10 May 2012 14:03:05 -0400

Hi Yiu,
      Let me ask a few questions...

> in IPv6. The app will continue to send the igmp-join (say 224.1.2.3).

How does the IPv4 IP-TV know to join 224.1.2.3?

How is 224.1.2.3 advertised to the IPv4 IP-TV clients if the content is 
generated by an IPv6 source?  Does the source need to be configured to 
use one of these IPv4-in-IPv6 multicast addresses?

> application and managed by the network.

Are you limiting this approach to only mapping at the IGMP/MLD protocols?

How does your Adaptive Function know which IPv6 multicast prefix to use 
when mapping the IPv4 multicast address in the IGMP Report message to MLD?

Regards,
Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 10 May 2012 16:07:05 -0500

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Brian Haberman

> How does the IPv4 IP-TV know to join 224.1.2.3?

My suggested answers would be:

The IP-TV server provider's EPG web site provides the IP-TV with the multicast group address.

> use one of these IPv4-in-IPv6 multicast addresses?

The EPG web server detects that the client IP-TV is using IPv4, so it provides the IPv4 address.

> when mapping the IPv4 multicast address in the IGMP Report message to

This has to be table lookup. The IPv6 prefix for these IPv4 multicast groups is always the same, or the service provider has a table that specifies the IPv6 prefix for use with each IPv4 group.

Bert

---

From: Tina TSOU <[email-masked]>
Date: Fri, 11 May 2012 00:01:53 +0000

Tina

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Haberman
> Sent: Thursday, May 10, 2012 11:03 AM
> To: Lee, Yiu
> Cc: [email-masked]; [email-masked] application-layer protocols;
> [email-masked]; The IESG;
> [email-masked]
> Subject: Re: [MBONED] APPSDIR review of draft-ietf-mboned-64-multicast-
> address-format-01
> 
> Hi Yiu,
http://datatracker.ietf.org/doc/draft-tsou-mboned-multrans-addr-acquisition/
Hope it helps.

---

From: <[email-masked]>
Date: Fri, 11 May 2012 08:41:46 +0200

Dear Brian,

Please see inline.

Cheers,
Med 

>De : Brian Haberman [mailto:[email-masked]] 
>Envoyé : jeudi 10 mai 2012 20:03
>À : Lee, Yiu
>Cc : Carsten Bormann; BOUCADAIR Mohamed OLNC/NAD/TIP; 
>[email-masked]; [email-masked]; The IESG; 
>[email-masked] application-layer protocols; 

Med: For this particular case (i.e., IPv4-only receiver over an IPv6 network+IPv4 source), the same discovery mechanism as for an IPv4-only network will be used. 

>generated by an IPv6 source? 

Med: The source is IPv4 but the IPv4-enabled receiver is connected to an IPv6-only network (e.g., http://tools.ietf.org/html/draft-ietf-softwire-dslite-multicast-02#section-4).

 Does the source need to be configured to 
>use one of these IPv4-in-IPv6 multicast addresses?

Med: This address is an address representing the IPv4 source in an IPv6 network. The source is not required to be aware of that address.

>Are you limiting this approach to only mapping at the IGMP/MLD 

Med: No. If the receiver is IPv6-enabled, it can build an IPv4-embedded IPv6 address if it has been configured with an MPREFIX64.

>when mapping the IPv4 multicast address in the IGMP Report 

Med: By configuration. Please refer to Section 6 of address format draft or http://tools.ietf.org/html/draft-ietf-softwire-dslite-multicast-02#section-5.

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 14 May 2012 20:50:05 +0000

Hi Brian,

Sorry for getting back late. I read Bert's answers to your questions. His
answers are inline with my answers. Most information are statically
configured. For example: Ch1 is statically configured to 224.1.2.3 via OOB
mechanism. If the STB is IPv4 only, it will only use IPv4 mcast address.
It won't use the address format defined in this draft. In my mind, the
most common deployment will use the same IPv6 prefix which will be
statically configured in the AF.

Regards,
Yiu

---

From: Stig Venaas <[email-masked]>
Date: Mon, 14 May 2012 13:56:16 -0700

> statically configured in the AF.

Right, so that was my main concern with the draft. Is static
configuration like this sufficient, or are there more generic cases
where one needs to know that it is translated from IPv4 without a
priori configuration. The flag bit (or a well-known prefix) is only
needed in the latter case. I know there were some scenarios where
someone found the latter to be advantageous though.

Stig

>
> Regards,
> Yiu
>
>
> On 5/10/12 2:03 PM, "Brian Haberman"<[email-masked]>  wrote:
>
>> Hi Yiu,

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 14 May 2012 21:06:02 +0000

Hi Stig,

Right. I explain only one use case. Other may find the latter case is more
attractive for their deployments. This address format should enable the
dynamic use case as well.

Yiu

On 5/14/12 4:56 PM, "Stig Venaas" <[email-masked]> wrote:

>>>> Thanks very much for reviewing the document. I just want to add a
>>>>point
>>>> to

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 15 May 2012 13:45:06 -0500

Hi Brian,

I think that there is a lot of confusion on the mails related to this
tread and some others regarding IPv4 IPv6 multicast work.

The confusion is stemming from the fact that multicast communication
is being abstracted from unicast communication.

I can not imagine any host being involved only in multicast
communication. In fact most of the communication will be in unicast.

For unicast communication, IETF has defined several transition
protocols, mostly in Softwire WG (ds-lite, 6rd, 4rd, etc.).

The right way to look at IPv4 IPv6 multicast is to look at these
unicast transition protocols and then define multicast protocols for
each.

In fact that is what we currently have. For each unicast transition
protocol we have a multicast transition protocol proposed/defined.

There is probably a single other component that is needed is the
address translation component. For this we have
draft-ietf-mboned-64-multicast-address-format.

However, there has been many objections to
draft-ietf-mboned-64-multicast-address-format because it is trying to
extend IP addressing architecture.

I do agree to those who say that we do not need to extend the
architecture and hope that a simpler solution can be found.

Please let's not get confused more and concentrate on finding the
right solution.

Regards,

Behcet

On Thu, May 10, 2012 at 1:03 PM, Brian Haberman
<[email-masked]> wrote:
> generated by an IPv6 source?  Does the source need to be configured to use
> one of these IPv4-in-IPv6 multicast addresses?
>
>
> How does your Adaptive Function know which IPv6 multicast prefix to use when
> mapping the IPv4 multicast address in the IGMP Report message to MLD?
>
> Regards,
> Brian
>

---

From: Jacni Qin <[email-masked]>
Date: Wed, 16 May 2012 09:20:41 +0800

Re-,

> dynamic use case as well.
Yes, imaging the coexistence of the native provisioning and the embedded 
address for some transition approach deployment, to perform that 
statelessly, a flag bit is efficient.

Cheers,
Jacni

> Yiu
>
> On 5/14/12 4:56 PM, "Stig Venaas"<[email-masked]>  wrote:
>