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

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 

>-----Message d'origine-----
>De : ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] De 
>la part de mohamed.boucadair@orange.com
>Envoyé : jeudi 16 août 2012 07:45
>À : Bob Hinden
>Cc : ipv6@ietf.org; 
>draft-ietf-mboned-64-multicast-address-format@tools.ietf.org; 
>Jacni Qin; Stig Venaas
>Objet : RE: draft-ietf-mboned-64-multicast-address-format
>
>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:bob.hinden@gmail.com] 
>>Envoyé : mardi 14 août 2012 17:33
>>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>>Cc : Bob Hinden; ipv6@ietf.org; Jacni Qin; 
>>draft-ietf-mboned-64-multicast-address-format@tools.ietf.org; 
>>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
>>
>>On Aug 14, 2012, at 2:09 AM, <mohamed.boucadair@orange.com> 
>><mohamed.boucadair@orange.com> wrote:
>>
>>> 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-addr
>ess-format-03.
>>>  
>>> Comments and suggestions are more than welcome.
>>>  
>>> Cheers,
>>> Med 
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>
>>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>ipv6@ietf.org
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------
>