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

From: <[email-masked]>
Date: Fri, 4 May 2012 14:50:29 +0200

Dear all,

During the IETF LC for draft-ietf-mboned-64-multicast-address-format, Brian suggested to use the remaining flag instead of reserving ff3x:0:8000/33 (SSM) and ffxx:8000/17 (ASM) blocks. FYI, we have considered that approach in an early version of the document but it has been abandoned because of comments we received at that time. We recorded the rationale behind our design choice in:
http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-01#appendix-A.2.

We are seeking more feedback from 6man and mboned on the following:

(1) Should we maintain the current design choice
(2) Or adopt the suggestion from Brian?

FWIW, discussion related to this issue can be found here: http://www.ietf.org/mail-archive/web/mboned/current/msg01508.html.
The latest version of the draft is available at: http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-01

Your help is appreciated.

Cheers,
Med

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 4 May 2012 14:29:30 -0500

I don't know why IPv6 becomes more arcane with every new I-D. Why not work to make it simpler, rather than more complex and confusing, with every new iteration?

In this particular case, it is really confusing to change the location of this new field, 64IX, depending whether it's ASM or SSM. And I might suggest to drop the 64IX nibble altogether. Use the remaining bit of the flgs field instead of the M bit of the 64IX field, and then allow for different combinations of the flgs bits for future codes?

Bert

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, May 04, 2012 8:50 AM
To: [email-masked]; [email-masked]
Cc: Brian Haberman; [email-masked]
Subject: draft-ietf-mboned-64-multicast-address-format

Dear all,

Cheers,
Med

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 4 May 2012 19:29:57 -0400

On Fri, May 4, 2012 at 3:29 PM, Manfredi, Albert E
<[email-masked]> wrote:
> I don’t know why IPv6 becomes more arcane with every new I-D. Why not work
> to make it simpler, rather than more complex and confusing, with every new
> iteration?
>

When you start with simplicity, experience will add complexity.

Regards
Marshall

>
>
> In this particular case, it is really confusing to change the location of
> this new field, 64IX, depending whether it’s ASM or SSM. And I might suggest
> to drop the 64IX nibble altogether. Use the remaining bit of the flgs field
> instead of the M bit of the 64IX field, and then allow for different
> combinations of the flgs bits for future codes?
>
>
>
> Bert
>
>
>
> Cc: Brian Haberman;
> [email-masked]
> During the IETF LC for draft-ietf-mboned-64-multicast-address-format, Brian
> suggested to use the remaining flag instead of reserving ff3x:0:8000/33
> (SSM) and ffxx:8000/17 (ASM) blocks. FYI, we have considered that approach
> in an early version of the document but it has been abandoned because of
> comments we received at that time. We recorded the rationale behind our
> design choice in:
>
> FWIW, discussion related to this issue can be found here:
> http://www.ietf.org/mail-archive/web/mboned/current/msg01508.html.
>
> The latest version of the draft is available at:
> http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-01
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Bob Hinden <[email-masked]>
Date: Sat, 5 May 2012 19:12:14 -0700

Med,

> The latest version of the draft is available at: http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-01

[personal hat on and co-author of RFC 4291]

I reviewed the draft and read through the thread you referred to.  

I don't think the approach defined in this draft is needed nor the resulting complexity it proposes adding to the IPv6 Address Architecture.  Instead of what is proposed one could reserve a block of group ids (33 or 33 bits worth) and eliminate all of the type bits at the front.

Or better yet, just keep a mapping table in the translator that maps the IPv4 multicast group to an IPv6 multicast group ID?  That wouldn't require any changes in the IPv6 multicast address.  If the purpose of these boxes is to do translation, then this should be possible, like is done with other forms of Network Address Translation (NAT).   This would also mean that you wouldn't need anything close to 2^^32 multicast groups as I suspect the number that will be used in practice will be much smaller.

My overall conclusion is that I don't see the need for any changes to the IPv6 addressing architecture to support this application.

Bob

---

From: Tom Taylor <[email-masked]>
Date: Mon, 07 May 2012 22:22:21 -0400

I'd like to respond to one of your points. Your overall thrust 
(preservation of the existing architure) is reasonable, but it is really 
useful operationally for nodes to be able to recognize IPv6 multicast 
addresses that contain embedded IPv4 multicast addresses. If the path 
taken by the signalling and, in the reverse direction, the multicast 
data crosses multiple points of transition between IPv4 and IPv6 or the 
reverse, the translation at each such transition point can be done 
independently, with no need to coordinate between the different 
translating nodes. That holds even across domain boundaries. If a 
mapping table is used instead, the same table has to be provisioned at 
each translating node.

On 05/05/2012 10:12 PM, Bob Hinden wrote:
...
>
> Or better yet, just keep a mapping table in the translator that maps
> the IPv4 multicast group to an IPv6 multicast group ID?  That
> wouldn't require any changes in the IPv6 multicast address.  If the
> purpose of these boxes is to do translation, then this should be
> possible, like is done with other forms of Network Address
> Translation (NAT).   This would also mean that you wouldn't need
> anything close to 2^^32 multicast groups as I suspect the number that
> will be used in practice will be much smaller.
>
> My overall conclusion is that I don't see the need for any changes to
> the IPv6 addressing architecture to support this application.
>
> Bob
>
>
...

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 7 May 2012 23:05:25 -0400

Dear Bob, et al.;

> Or better yet, just keep a mapping table in the translator that maps the IPv4 multicast group to an IPv6 multicast group ID?  That wouldn't require any changes in the IPv6 multicast address.  If th…

Here is a potential way to do this that I have not seen discussed yet
for this. If it has been, my apologies and a pointer to the discussion
would be appreciated.

If DNS can be used to do "SSM Mapping" for IGMPv2  (i.e., use the
group address to create a domain name and use that to come up with an
appropriate Source address using reverse DNS lookup - see

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t2/feature/guide/gtssmma.html
http://www.juniper.net/techpubs/en_US/junos10.3/topics/example/multicast-ssm-mapping.html
),

then I don't see why the same trick can't be applied for IPv4 <-> IPv6
translation mappings.
This seems like the sort of thing that could be  implemented very
quickly, and does away with the need for mapping tables.

Regardless of how is it is done, I see no reason to and would be
against reserving the 4th (last) Flag in the 4291 multicast address
format for this purpose.

Regards
Marshall

---

From: <[email-masked]>
Date: Wed, 23 May 2012 15:20:50 +0200

Dear all,

Many thanks for the individuals who read the draft and provided some comment.

My read of the the answers received in this thread is there is no strong reasons to question the design choices as documented in the draft.

FWIW, I just submitted a updated version taking into account the comments received during the IETF LC:

* Editorial changes as suggested in SM's review
* Title change (comment from C. Bormann)
* Added a new section to describe the algorithm to embed/extract the IPv4 address (comment from C. Bormann)
* Added some pointers to documents making use of the address format (comment from C. Bormann)
* Added an appendix to explain why an M-bit is needed (comment from C. Bormann)
* Added an appendix to explain why an address format is needed (comment from C. Bormann)
* Added examples of means to provision the MPREFIX64 (comment from C. Bormann)

Diff from previous version:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-mboned-64-multicast-address-format-02

Cheers,
Med

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : vendredi 4 mai 2012 14:50
À : [email-masked]; [email-masked]
Cc : Brian Haberman; [email-masked]
Objet : draft-ietf-mboned-64-multicast-address-format

Dear all,

Cheers,
Med

---

From: Bob Hinden <[email-masked]>
Date: Wed, 23 May 2012 09:38:24 -0700

Med,

> My read of the the answers received in this thread is there is no strong reasons to question the design choices as documented in the draft.

Did you see my comments sent on 5/5/2012?  I continue to think that there are alternatives that do not require any change to the IPv6 addressing architecture, nor use such a big percentage of the multicast group ID space.

Bob

---

From: <[email-masked]>
Date: Thu, 24 May 2012 07:38:18 +0200

Dear Bob,

Yes, I read that message. It is one of reasons I added two appendixes to explain:

* Why an Address Format is Needed for Multicast IPv4-IPv6 Interconnection? (http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-02#appendix-A.1)
* Why Identifying an IPv4-Embedded IPv6 Multicast Address is Required? (http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-02#appendix-A.2)

You may also refer to slide 7 of http://www.ietf.org/proceedings/83/slides/slides-83-mboned-5.pdf for the overall approach.

Could you please check the new text and let me know if it solves your concerns? Thanks.

Cheers
Med

>-----Message d'origine-----
>De : Bob Hinden [mailto:[email-masked]] 
>Envoyé : mercredi 23 mai 2012 18:38
>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : Bob Hinden; [email-masked]
>Objet : Re: draft-ietf-mboned-64-multicast-address-format
>
>Med,
>
>> My read of the the answers received in this thread is there 
>is no strong reasons to question the design choices as 
>documented in the draft.
>
>Did you see my comments sent on 5/5/2012?  I continue to think 
>that there are alternatives that do not require any change to 
>the IPv6 addressing architecture, nor use such a big 
>percentage of the multicast group ID space.
>
>Bob
>
>
>>  
>> FWIW, I just submitted a updated version taking into account 
>the comments received during the IETF LC:
>>  
>> * Added a new section to describe the algorithm to 
>embed/extract the IPv4 address (comment from C. Bormann)
>> Cc : Brian Haberman; 
>> During the IETF LC for 
>draft-ietf-mboned-64-multicast-address-format, Brian suggested 
>to use the remaining flag instead of reserving ff3x:0:8000/33 
>(SSM) and ffxx:8000/17 (ASM) blocks. FYI, we have considered 
>that approach in an early version of the document but it has 
>been abandoned because of comments we received at that time. 
>We recorded the rationale behind our design choice in:
>>

---

From: Bob Hinden <[email-masked]>
Date: Fri, 25 May 2012 17:25:40 -0700

Med,

> Yes, I read that message. It is one of reasons I added two appendixes to explain:

Not seeing a response on the list, it wasn't clear to me.  

> * Why an Address Format is Needed for Multicast IPv4-IPv6 Interconnection? (http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-02#appendix-A.1)

This just restates that you want the translator to be stateless.  I understand that.

> * Why Identifying an IPv4-Embedded IPv6 Multicast Address is Required? (http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-02#appendix-A.2)

The issue isn't why embedding the IPv4 multicast address in the IPv6 multicast address is needed, the issue is the way you do it.

Appendix A2 does not address one of the alternatives I described where you would preallocate (and register at the IANA) a group of multicast group IDs (~ 2^^28).  This would allow a 1:1 stateless mapping function.  It would avoid any changes to the IPv6 addressing architecture, and would use much less of the IPv6 multicast address space.  Your current proposal reduces the IPv6 multicast group space by a factor of 16 in the ASM case, and a factor of 16 million in the SSM case.  This is very wasteful given you only need to represent 2^^28 total possible IPv4 multicast groups.  

> Could you please check the new text and let me know if it solves your concerns? Thanks.

My concern remains.

Bob

---

From: Jon Steen <[email-masked]>
Date: Fri, 25 May 2012 23:09:16 -0400

Sorry all, coming into this late. I have read the RFC and really do not get
why you would want to do IPv4 to IPv6 multicast translation.  Is there
really multicast information that is only IPv4 capable? From everything I
have used multicast for in the past, the data does not care about the IP
protocol used. What is the reliance of this RFC?

Jon Steen

On Friday, May 25, 2012, Bob Hinden wrote:

> Med,
>
> On May 23, 2012, at 10:38 PM, <[email-masked] <javascript:;>>
> <[email-masked] <javascript:;>> wrote:
>
> > Dear Bob,
> >
> > * Why an Address Format is Needed for Multicast IPv4-IPv6
> Interconnection? (
> http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-02#appendix-A.1
> )
>
> > * Why Identifying an IPv4-Embedded IPv6 Multicast Address is Required? (
> http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-02#appendix-A.2
> )
>
>
> The issue isn't why embedding the IPv4 multicast address in the IPv6
> multicast address is needed, the issue is the way you do it.
>
> Appendix A2 does not address one of the alternatives I described where you
> would preallocate (and register at the IANA) a group of multicast group IDs
> (~ 2^^28).  This would allow a 1:1 stateless mapping function.  It would
> avoid any changes to the IPv6 addressing architecture, and would use much
> less of the IPv6 multicast address space.  Your current proposal reduces
> the IPv6 multicast group space by a factor of 16 in the ASM case, and a
> factor of 16 million in the SSM case.  This is very wasteful given you only
> need to represent 2^^28 total possible IPv4 multicast groups.
>
> >
> > You may also refer to slide 7 of
> http://www.ietf.org/proceedings/83/slides/slides-83-mboned-5.pdf for the
> overall approach.
> >
> >>> FWIW, discussion related to th

-- 
Jon Steen
106 Apple Creek Road
Frederick, MD 21702

---

From: Tom Taylor <[email-masked]>
Date: Sat, 26 May 2012 11:06:23 -0400

I think there's a misunderstanding here. The only requirement is to 
translate the IP headers. The document in question deals with the 
address translation part of that task.

...