Subject: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D

From: <[email-masked]>
Date: Wed, 9 Feb 2011 10:23:06 +0100

Dear all,

Together with Jacni, Yiu, Stig, Xing, and Mingwei we worked on an updated version of the  multicast IPv4-embedded address format I-D:

http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-format-01

We still have some discussion points, e.g.- whether we allow or not ASM IPv4==>SSM IPv6, SSM IPv4==>ASM IPv6. The current text says we should not but we still need to assess whether there are valid use cases for relaxing this.

Cheers,
Med
*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Stig Venaas <[email-masked]>
Date: Wed, 09 Feb 2011 10:29:02 -0800

> We still have some discussion points, e.g.- whether we allow or not ASM IPv4==>SSM IPv6, SSM IPv4==>ASM IPv6. The current text says we should not but we still need to assess whether there are valid…

My opinion is that there should be no restrictions on this. This
embedding in itself should be very generic, and we may not know
what uses people may come up with. If we standardize mechanisms
making use of this embedding, then those may have restrictions.

Let me try to describe a scenario where I can see a use for mixing
ASM and SSM.

Let us consider an IPv6 SSM-only network receiving IPv4 ASM
multicast from an IPv4 network.

Assuming that the relevant IPv4 groups have a single source
each (which is fairly common), you can have a translator
with a fixed IPv6 unicast address used for sending translated
IPv4 multicast, call it S6.

In the IPv6 network, for each IPv4 group G4, you take the
translators address S6 and use the IPv4-embedded multicast
format to construct say G6 = embed(G4). So the receivers
in the IPv6 network use SSM to join (S6,G6). This reaches
the translator, which then knows it should join G4 (the
last 32 bits of G6).

If there are multiple sources sending to G4, this may
still work for e.g. RTP. Basically if the translator
receives packets from S4 and S4', they could both be
translated to (S6,G6). The RTP header is sufficient for
the receiver to distinguish the streams.

Stig

---

From: Jacni Qin <[email-masked]>
Date: Thu, 10 Feb 2011 14:54:01 +0800

Dear Stig,

Inline please,

On Thu, Feb 10, 2011 at 2:29 AM, Stig Venaas <[email-masked]> wrote:

>> Together with Jacni, Yiu, Stig, Xing, and Mingwei we worked on an updated
>> version of the  multicast IPv4-embedded address format I-D:
>>
>>
>> We still have some discussion points, e.g.- whether we allow or not ASM
>> IPv4==>SSM IPv6, SSM IPv4==>ASM IPv6. The current text says we should not
>> but we still need to assess whether there are valid use cases for relaxing
>> this.
>>
>

Jacni>: I understand your case and elaboration below, while I'm a little
concerned by the "SSM-Only network".
Is it not capable of ASM indeed, or just restricted by deployment policies?
Anyway, if the ASM mode is supported, I'd rather pick one ASM_MPREFIX64 to
map the IPv4 ASM multicast, and avoid the complexity. Even there are native
SSM receivers, it is not difficult to be compatible with ASM, right?

Cheers,
Jacni

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: <[email-masked]>
Date: Thu, 10 Feb 2011 08:05:03 +0100

Hi Stig,

I see your scenario even if I would check first whether it is feasible or not to use ASM in the IPv6 side. 
In my context, I don't have such scenario because we are using SSM mode (for the delivery of IPTV).

In the scenario you described, ** no ** address synthesis  of the IPv6 source addresses is allowed in the receiver side. S6 should be notified somehow to the receivers. The 64 interconnection function should not use RFC6052 for to represent the IPv4 source in the IPv6 domain.

It is possible to relax the constraint of mapping ASM<=>SSM by providing some guidelines to the IPv4-IPv6 interconnection function and to the receiver such as:

* When SSM_PREFIX64 and ASM_PREFIX64 are configured, only ASM<=>ASM and SSM<=>SSM synthesis are allowed.
* If only one MPREFIX64 is provisioned to the interconnection function, both ASM and SSM @es ca ne be mapped using MPREFIX64; still the interconnection function need to be configured with the source IPv6 address to use or rely on RFC6052. 

I don't know if this adds more complexity or not. 

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Stig Venaas
Envoyé : mercredi 9 février 2011 19:29
À : 'behave' ([email-masked])
Objet : Re: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D

Stig

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 10 Feb 2011 20:33:51 +0000

Hi Stig,

I read Jacni and Med's replies. In your scenario, the IX function must be
configured to know what PREFIX to be used for the SSMv6<==>ASMv4
translation. AFAIK, this can be done by the IPv6-embedded address format,
no new requirement is required. However, this will complicate the IX
implementation which is beyond the discussion of this draft.

Cheers,
/Yiu

On 2/9/11 1:29 PM, "Stig Venaas" <[email-masked]> wrote:

>> Together with Jacni, Yiu, Stig, Xing, and Mingwei we worked on an
>>updated version of the  multicast IPv4-embedded address format I-D:
>>
>> 
>>IPv4==>SSM IPv6, SSM IPv4==>ASM IPv6. The current text says we should
>>not but we still need to assess whether there are valid use cases for
>>relaxing this.
>

---

From: Stig Venaas <[email-masked]>
Date: Thu, 10 Feb 2011 13:15:25 -0800

> implementation which is beyond the discussion of this draft.

Let me try to answer all the replies I've seen.

I'm not sure if my scenario is a good one, and maybe the IPv6
site should support ASM, but if someone wants to do something
like this, then it is bad if we make it illegal.

I would like this format to be generic and support all the
different cases where you may want to embed an IPv4 multicast
address in an IPv6 multicast address.

If we restrict the usage, then it must be for a good reason.
If some use case or implementation only accepts ASM in ASM, then
they can check the address and discard it if say SSM in ASM.

Can you guys provide examples or reasons for restricting it?
I will also try to think about reasons both for and against,

Stig

> Cheers,
> /Yiu
>
>
> On 2/9/11 1:29 PM, "Stig Venaas"<[email-masked]>  wrote:
>

---

From: <[email-masked]>
Date: Fri, 11 Feb 2011 14:00:34 +0100

Hi Stig,

I don't have a strong opposition to relax it. My point is if we want to allow ASM<==>SSM, we need to describe the implications of such choice. I provided an example of the provisioning of the MPREFIX64 and also the impact on the discovery of the source IPv6 address.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Stig Venaas
Envoyé : jeudi 10 février 2011 22:15
À : Lee, Yiu
Cc : 'behave' ([email-masked])
Objet : Re: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D

Stig

---

From: Xing Li <[email-masked]>
Date: Sat, 12 Feb 2011 15:11:59 +0800

> like this, then it is bad if we make it illegal.

The CERNET2 IPv6-only backbone is an example, which provides IPv6 
unicast and SSM services. The customer's ASM application is provided 
cross SSM backbone.

> address in an IPv6 multicast address.

Agree. Since we are talking about IPv4/IPv6 interaction, if we believe 
there will be IPv6-only Internet in the future, we should define as 
little as possible in the transition and coexistent time.

Regards,

xing

>>>> http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-fo 
>>>>
>>>> rmat-01
>>>>

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 14 Feb 2011 15:07:22 +0000

Hi Stig and Xing,

I tried to answer both emails together. See inline.

Cheers,
Yiu

>unicast and SSM services. The customer's ASM application is provided

[YL] This is a valid use case. I am just curious how the ASM-SSM
translation happens. How does the translator learns the IPv6 source of the
SSM? Do you provision some kind of mapping?

>little as possible in the transition and coexistent time.

[YL] I also agreed.

>> I will also try to think about reasons both for and against,

[YL] No, I disagree to restrict this. We are on the same page. We should
remove the current restriction from the ID.

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 15 Feb 2011 09:49:30 -0800 (PST)

Hi Med,
  Can you please enlighten me 

 The address format defined in this document applies for both IPv4-
   IPv6 translation and encapsulation schemes.

why it would be needed for encapsulation schemes by referring to 

draft-qin-softwire-dslite-multicast

Thanks,

Behcet

---

From: <[email-masked]>
Date: Wed, 16 Feb 2011 07:17:00 +0100

Hi Behcet,

draft-qin-softwire-dslite-multicast is only an example of a solution using the proposed address format for its operations. draft-xu-softwire-mesh-multicast is another solution requiring an address format for embedding IPv4 multicast addresses in an IPv6 Mcst.

Concretely, draft-qin-softwire-dslite-multicast uses the proposed address format to allow:
* Stateless interworking between IGMPvx-MLD in the CPE
* Stateless IPv6-IPv4 PIM interworking 
* Stateless encap of IPv4 multicast flows at the v4-v6 interconnection nodes
* No coordination is required between all the interworking function except the provisioning of a SSM or ASM Multicast_PREFIX64.

Cheers,
Med

-----Message d'origine-----
De : Behcet Sarikaya [mailto:[email-masked]] 
Envoyé : mardi 15 février 2011 18:50
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : 'behave' <([email-masked])>
Objet : Re: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D

Hi Med,

Thanks,

Behcet

********************************************************************************

IMPORTANT. 
Les informations contenues dans ce message électronique y compris les fichiers attachés sont strictement confidentielles et peuvent être protégées par la loi.
Ce message électronique est destiné exclusivement au(x) destinataire(s) mentionné(s) ci-dessus. 
Si vous avez reçu ce message par erreur ou s'il ne vous est pas destiné, veuillez immédiatement le signaler à l'expéditeur et effacer ce message et tous les fichiers éventuellement attachés.
Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. 
Tout message électronique est susceptible d'altération.
A ce titre, le Groupe France Télécom décline toute responsabilité notamment s'il a été altéré, déformé ou falsifié.
De même, il appartient au destinataire de s'assurer de l'absence de tout virus.
  
IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure of this message is prohibited. 
Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.

********************************************************************************

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 16 Feb 2011 08:01:41 -0800 (PST)

> Hi Behcet,
> 
> draft-qin-softwire-dslite-multicast is only an example of a  solution using the 
>proposed address format for its operations.  draft-xu-softwire-mesh-multicast is 
>another solution requiring an address format  for embedding IPv4 multicast 
>addresses in an IPv6 Mcst.
> 
> * No coordination is required between all the  interworking function except the 
>provisioning of a SSM or ASM  Multicast_PREFIX64.
> 

This is one way but IMHO it would be totally unnecessary to use IPv4-embedded 
IPv6 address. I can not see the need for it except that you want to do multicast 
routing in the access network.

If you can lift this "requirement" then there is a much simpler solution, I 
suggest looking into draft-ietf-multimob-pmipv6-base-solution

Regards,

Behcet

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 18 Feb 2011 01:39:01 +0000

Hi Behect,

We are doing IPv4 multicast in the access network today. I foresee we will
continue to do IPv6 multicast in the access network in the future. IMHO,
multimob-pmipv6-base-solution is not simpler because it will require the
fixed line operator to implement PMIP. I don't see this is a simple
requirement.

Regards,
Yiu

>> Objet : Re: [BEHAVE]  Updated version of multicast IPv4-embedded
>>address format 
>>I-D
>> 
>> Hi  Med,

---

From: Xing Li <[email-masked]>
Date: Fri, 18 Feb 2011 13:35:09 +0800

> SSM? Do you provision some kind of mapping?

Currently, it is via distributed servers.

xing

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 18 Feb 2011 08:14:23 -0800 (PST)

> continue to do IPv6 multicast in the access network in the  future. 

No comments on this.

>IMHO,

No that's not true.

Regards,

Behcet

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 18 Feb 2011 16:17:11 +0000

Hi Behcet,

>> fixed line operator to implement PMIP. I don't see this is a  simple

Can you elaborate this a little more because I am not familiar with
multimob-pmipv6-base-solution? I am very interested to see how this can be
implemented in fixed line network and can simplify the multicast
translation.

Thanks,

Yiu