Subject: draft-ietf-mboned-64-multicast-address-format

From: <[email-masked]>
Date: Tue, 14 Aug 2012 11:09:24 +0200

Dear all,

I'm initiating this thread in the hope of understanding the
objections from the 6man WG and hopefully to make some progress for
this document.  To initiate the discussion, below are provided some
preliminary Q/A:

What is the scope of this document?
   The document specifies an algorithmic translation of an IPv6
   multicast address to a corresponding IPv4 multicast address, and
   vice versa.  The document reserves two IPv6 multicast prefixes to
   be used for that purpose.

What are these reserved prefixes?
   *  ff3x:0:8000::/96 for SSM
   *  ffxx:8000::/20 for ASM

Does this document update IPv6 addressing architecture?
   No.

Is there a unicast counterpart of this proposal?
   Yes, RFC6052.

What is the problem to be solved?
   There are several use cases as detailed in [I-D.ietf-mboned-v4v6-
   mcast-ps].  In particular, the following use cases are of
   interest:
   1.  An IPv6-only receiver wants to receive multicast content from
       an IPv4-only source (6-4).
   2.  An IPv4 receiver wants to join a multicast group in IPv4
       domain via an IPv6-only network (4-6-4).

Are there solutions for the unicast counterpart of these use cases?
   Yes; various solutions including:
   1.  6-4: RFC6146
   2.  4-6-4: RFC6333, RFC6346, ...

The latest version of the document is available at:
https://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-03.

Comments and suggestions are more than welcome.

Cheers,
Med

---

From: Bob Hinden <[email-masked]>
Date: Tue, 14 Aug 2012 08:33:19 -0700

Med,

The new draft appears to have many changes from the previous version.  It would be helpful if you could describe the changes.  This is usually done in the draft itself, but I didn't see it in -03.

Thanks,
Bob

On Aug 14, 2012, at 2:09 AM, <[email-masked]> <[email-masked]> wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 14 Aug 2012 11:40:20 -0500

>    2.  4-6-4: RFC6333, RFC6346, ...

I don't understand why RFC 6333 is included here.
If you take a look at
http://tools.ietf.org/html/draft-sarikaya-softwire-dslitemulticast-01
there is no need for this draft.

Related to this is this statement in the abstract:

This
   algorithmic translation can be used in both IPv4-IPv6 translation or
   encapsulation schemes.

I suggest removing encapsulation from the above sentence.

I have concerns on the way this draft justifies these new prefixes. I
think the justification should be completely based on translation. If
this basis is taken, the rest of the text will flow naturally.

Regards,

Behcet

---

From: Stig Venaas <[email-masked]>
Date: Tue, 14 Aug 2012 09:51:38 -0700

> there is no need for this draft.

If I understand your draft correctly, it uses unicast for the
encapsulation, then there is no need for this.

But e.g. draft-ietf-softwire-dslite-multicast-02 needs it. If you are
using multicast encapsulation (4 in 6), you need to know which group G
or (S,G) to join at the tunnel egress point. And at the ingress, you
need to interpret the IPv6 join you receive and extract the IPv4 address
to know which IPv4 group is requested. For the latter part you could
possibly encapsulate the joins, but I think that is not so good. Anyway,
you need it for the first part.

Encapsulation is very similar to translation. The only real difference
I see, is that when you receive packets at the egress, you can just do
decap, you don't need to figure out what the addresses in the new header
should be.

Stig

---

From: <[email-masked]>
Date: Thu, 16 Aug 2012 07:44:31 +0200

Dear Bob,

The main changes in -03 are as follows:

* Abandon the M-bit idea to represent IPv4-embedded IPv6 multicast prefix

* Explain the rationale for selecting a /96 (SSM) and /20 (ASM)

* Reserve two prefixes to be used for the algorithmic translation of an IPv6 multicast address into an IPv4 one; and vice versa
(1) ff3x:0:8000::/96 for SSM
(2) ffxx:8000::/20 for ASM

* The document does not update RFC4291; i.e., no change to the IPv6 addressing architecture.
 
Cheers,
Med

>-----Message d'origine-----
>De : Bob Hinden [mailto:[email-masked]] 
>Envoyé : mardi 14 août 2012 17:33
>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : Bob Hinden; [email-masked]; Jacni Qin; 
>[email-masked]; 
>Stig Venaas
>Objet : Re: draft-ietf-mboned-64-multicast-address-format
>
>Med,
>
>The new draft appears to have many changes from the previous 
>version.  It would be helpful if you could describe the 
>changes.  This is usually done in the draft itself, but I 
>didn't see it in -03.
>
>Thanks,
>Bob
>

---

From: <[email-masked]>
Date: Thu, 16 Aug 2012 07:51:48 +0200

Hi Behcet,

Please see inline. 

Cheers,
Med 

>De : Behcet Sarikaya [mailto:[email-masked]] 
>Envoyé : mardi 14 août 2012 18:40
>Cc : [email-masked]; Jacni Qin; 

Med: RFC6333 is provided as an example of a unicast solution for the 4-6-4 case.

>there is no need for this draft.

Med: Yes, because you are using unicast not multicast capabilities between the AFTR and the CPE. The solution adopted in softwire (http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-multicast/) makes use of native multicast capabilities to deliver IPv4 content over an IPv6 network.
 
>I suggest removing encapsulation from the above sentence.

Med: The algorithmic translation is about address translation not the way packets are constructed...which applies for both encap and translation. Specific solutions design is out of scope.

---

From: <[email-masked]>
Date: Fri, 24 Aug 2012 10:50:20 +0200

Dear all,

FYI, a new version of this draft has been edited to take into account comments received in mboned ML. 
The main changes in -04 are as follows:

   o  Indicate the draft update RFC3306 as suggested by T. Chown.  We
      didn't added a note about rfc3956 as we are defining a bit
      reserved in 3306.

   o  Because of the previous comment, the wording has been changed to
      indicate we are reserving a bit in the unicast prefix-based
      address not reserving a prefix for ASM.  The rationale behind that
      is to encourage implementations check the value of the
      reserved bit rather than matching a prefix.

   o  Clarify the meaning of "x" as requested by Behcet.

   o  Behcet asked to reserve a /17 or /12 for ASM.  We didn't considered
      that comment because we received in the past comments arguing that
      reserving /17 is a waste of multicast address space.  This is
      documented in Section 3.1 of the draft.

   o  Implemented some wording changes suggested by P. Koch.

   o  Update the section with examples.

A detailed diff is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mboned-64-multicast-address-format-04.

Cheers,
Med 

>De : [email-masked] [mailto:[email-masked]] De 
>la part de [email-masked]
>Envoyé : jeudi 16 août 2012 07:45
>À : Bob Hinden
>Cc : [email-masked]; 
>Jacni Qin; Stig Venaas
>Objet : RE: draft-ietf-mboned-64-multicast-address-format
>
>Dear Bob,
>
>* Reserve two prefixes to be used for the algorithmic 
>translation of an IPv6 multicast address into an IPv4 one; and 
>vice versa