Subject: [MBONED] Last Call: <draft-ietf-mboned-64-multicast-address-format-01.txt> (IPv4-Embedded IPv6 Multicast Address Format) to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 18 Apr 2012 15:33:48 -0700

The IESG has received a request from the MBONE Deployment WG (mboned) to
consider the following document:
- 'IPv4-Embedded IPv6 Multicast Address Format'
  <draft-ietf-mboned-64-multicast-address-format-01.txt> as a Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2012-05-02. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document specifies an extension to the IPv6 multicast addressing
   architecture to be used in the context of IPv4-IPv6 interconnection.
   In particular, this document defines an address format for IPv4-
   embedded IPv6 multicast addresses.  This address format can be used
   for IPv4-IPv6 translation or encapsulation schemes.

   This document updates RFC4291.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mboned-64-multicast-address-format/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mboned-64-multicast-address-format/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Brian Haberman <[email-masked]>
Date: Fri, 20 Apr 2012 08:36:55 -0400

All,
      Apologies for not having reviewed this document earlier, but I 
have a fair number of comments on this approach...

* Without any supporting documentation, it is unclear how this address 
format is supposed to be utilized. This type of specialized address 
format is better defined in a document that *uses* the format.  This 
allows readers to derive the complete set of functionality needed to 
support a new address format.

* Why is there a new set of flags (64IX) being created within the 
address?  There is only one bit being used in that field and there is 
still a bit available in the standard flags field.  Why is that not 
being used to indicate a "translatable" multicast address?

* What is the purpose/use of the sub-group-id field?

* The use of IPv4 multicast addresses in the lowest 32-bits of the IPv6 
address needs to be reconciled with the multicast allocation guidelines 
in RFC 3307.  Specifically, using IPv4 multicast addresses (0xE0000000 
to 0xEFFFFFFF) overlaps with the range of IPv6 addresses reserved for 
dynamically generated addresses, which requires the T bit to be set in 
the prefix.

* Why is the existing format of multicast addresses (RFC 3306) not 
sufficient?  The 'M' bit can be defined within the existing flags, the 
sub-group-id can overlay the network prefix, and any additional bits 
needed can overlay the reserved field. This eliminates the need for any 
type of varying format based on whether the address in question is ASM 
or SSM.

|   8    |  4 |  4 |   8    |    8   |       64       |    32    |
+--------+----+----+--------+--------+----------------+----------+
|11111111|0RPT|scop|reserved|  plen  | network prefix | group ID |
+--------+----+----+--------+--------+----------------+----------+

becomes

|   8    |  4 |  4 |   8    |    8   |       64       |    32    |
+--------+----+----+--------+--------+----------------+----------+
|11111111|MRPT|scop|reserved|  plen  |  sub-group-id  | v4 addr  |
+--------+----+----+--------+--------+----------------+----------+

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Fri, 20 Apr 2012 13:47:46 -0400

On 4/20/12 12:58 PM, Stig Venaas wrote:

>> still a bit available in the standard flags field. Why is that not being
>> used to indicate a "translatable" multicast address?
>
> Hi, just a comment on this one. Unfortunately these are not treated as
> individual bits. For instance implementations have hardcoded that the
> flag nibble 3 is SSM (and also what is specified in various RFC), so if

I consider it unfortunate that people interpreted RFC 3306 as specifying 
a hard-coded SSM prefix when there are undefined flag bits present in 
the prefix.

The implementation I worked on didn't blindly check for a fixed prefix. 
  That was intentional given the existence of two bits in the flgs field 
that were undefined.

> this bit is set, it would not be treated as SSM without a number of
> documents and implementations being updated. Same issue with
> Embedded-RP. I know this is unfortunate. Do you see it differently? I
> think we need a new field that is a true flag field.

Sorry, I don't see it any differently.  I would file bug reports with 
implementations that make that assumption, but I would not use that as 
justification to change an address architecture.

Regards,
Brian

---

From: Stig Venaas <[email-masked]>
Date: Fri, 20 Apr 2012 11:05:15 -0700

> a hard-coded SSM prefix when there are undefined flag bits present in

Me too, but I don't blame them, see below.

> justification to change an address architecture.

OK, I've seen implementations using a fixed value, which I think is
unfortunate. I wouldn't mind if we investigate this further.

I can check some Cisco implementations to see what they are doing. Maybe
people from other vendors could check too.

Regarding RFCs.

RFC 3306:

6. Source-Specific Multicast Addresses

    The unicast prefix-based IPv6 multicast address format supports
    Source-specific multicast addresses, as defined by [SSM ARCH].  To
    accomplish this, a node MUST:

          o  Set P = 1.
          o  Set plen = 0.
          o  Set network prefix = 0.

    These settings create an SSM range of FF3x::/32 (where 'x' is any
    valid scope value).  The source address field in the IPv6 header
    identifies the owner of the multicast address.

This is sort of OK, but it doesn't mention that there may be other SSM
ranges.

RFC 4607:

    For IPv6, the address prefix FF3x::/32 is reserved for source-
    specific multicast use, where 'x' is any valid scope identifier, by
    [IPv6-UBM].  Using the terminology of [IPv6-UBM], all SSM addresses
    must have P=1, T=1, and plen=0.  [IPv6-MALLOC] mandates that the
    network prefix field of an SSM address also be set to zero, hence all
    SSM addresses fall in the FF3x::/96 range.  Future documents may
    allow a non-zero network prefix field if, for instance, a new IP-
    address-to-MAC-address mapping is defined.  Thus, address allocation
    should occur within the FF3x::/96 range, but a system should treat
    all of FF3x::/32 as SSM addresses, to allow for compatibility with
    possible future uses of the network prefix field.

It should also talk about FFBx then.

RFC 3956:

    The behavior is unspecified if P or T is not set to 1, as then the
    prefix would not be FF70::/12.  Likewise, the encoding and the
    protocol mode used when the two high-order bits in "flgs" are set to
    11 ("FFF0::/12") is intentionally unspecified until such time that
    the highest-order bit is defined.  Without further IETF
    specification, implementations SHOULD NOT treat the FFF0::/12 range
    as Embedded-RP.

But based on this, implementations following this SHOULD, would also
need to be updated.

With what was proposed in the draft, there is no need to update every
router to use Embedded-RP, only the ones that need to be aware of
translation taking place. If we define a new flag, Embedded-RP
implementations will need to change.

Regarding the flags in this document. My initial thought was having
well-known prefixes for embedding v4 in v6, both ASM and SSM. You
may think of this draft as defining well-known prefixes, rather
than a new flag.

Stig

---

From: Brian Haberman <[email-masked]>
Date: Sat, 21 Apr 2012 11:56:28 -0400

On 4/20/12 2:05 PM, Stig Venaas wrote:
>>>> being

I agree that those RFCs are nebulous, but they can be clarified by 
either filing errata or proposing an update.

> implementations will need to change.

How can you possibly know *which* routers are going to be aware, or will 
need to be aware, of translation taking place?

> may think of this draft as defining well-known prefixes, rather

And my feedback is still the same.  The approach you are taking is 
diverging from a structured format that can be made to work for this 
problem.  I don't see any benefit in this divergence.

Regards,
Brian

---

From: <[email-masked]>
Date: Mon, 23 Apr 2012 10:34:04 +0200

Dear Brian,

Thank you for the comments.

Please see inline.

Cheers,
Med 

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] 
>De la part de Brian Haberman
>Envoyé : vendredi 20 avril 2012 14:37
>À : [email-masked]; 
>[email-masked]
>Objet : Re: [MBONED] Last Call: 
><draft-ietf-mboned-64-multicast-address-format-01.txt>
>
>All,

Med: Sure but there are plenty of documents 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 those pointers and adopted the same approach as RFC6052: only the address format is defined while the usage is defined in other companion documents.

>being used to indicate a "translatable" multicast address?

Med: We have considered the use of the remaining flag, but we abandoned it for the reasons documented in: http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-01#appendix-A.1:

"
   It was tempting to use the remaining flag to indicate whether an IPv6
   address embeds an IPv4 address or not.  This choice has been
   abandoned by the authors for various reasons:
   o  ff3x::/32 is defined as SSM.  Defining a new flag would require
      standards and implementations to also treat ffbx::/32 as SSM.
   o  Prefixes starting with ff7x are defined as embedded-RP, but not
      prefixes starting with fffx.  Below is provided an excerpt from
      [RFC3956]:
         " ...the encoding and the protocol mode used when the two high-
         order bits in "flgs" are set to 11 ("fff0::/12") is
         intentionally unspecified until such time that the highest-
         order bit is defined.  Without further IETF specification,
         implementations SHOULD NOT treat the fff0::/12 range as
         Embedded-RP."
         as such defining a new flag would require implementations to
         also treat ff7x::/12 as embedded-RP prefix.
   o  This is the last remaining flag and at this stage we are not sure
      whether there is other usage scenarios of the flag.

   As a conclusion, the remaining flag is not used to indicate an IPv6
   multicast address embeds an IPv4 multicast address.  However the
   following constraints should be met:

      (1) Belong to ff3x::/32 and be compatible with unicast-based
      prefix [RFC3306] for SSM.  Note that [RFC3306] suggests to set
      "plen" to 0 and "network-prefix" to 0.
      (2) Be compatible with embedded-RP [RFC3956] and unicast-based
      prefix [RFC3306] for ASM;
      (3) Avoid ff3x::4000:0001-ff3x::7fff:ffff which is reserved for
      IANA.
   Meeting (1) and (2) with the same location of the M-bit is not
   feasible without modifying embedded-RP and unicast-based prefix
   specifications; this option is avoided.

   As a consequence, two multicast blocks are proposed to be used when
   embedding IPv4 address: one block for ASM (Section 3 ) and another
   one for the SSM (Section 4).
"

Could you please check whether this clarifies your concern?

>* What is the purpose/use of the sub-group-id field?

Med: The document reads: 

   o  sub-group-id: This field is configurable according to local
      policies of the entity managing the IPv4-IPv6 Interconnection
      Function.  This field must follow the recommendations specified in
      [RFC3306] if unicast-based prefix is used or the recommendations
      specified in [RFC3956] if embedded-RP is used.  The default value
      is all zeros.

>dynamically generated addresses, which requires the T bit to be set in 

Med: Could you please explicit what the document should say? Thanks for your help.

>type of varying format based on whether the address in question is ASM 

Med: See above.

>
>Regards,
>Brian
>_______________________________________________
>MBONED mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mboned
>

---

From: Brian Haberman <[email-masked]>
Date: Mon, 23 Apr 2012 08:23:56 -0400

On 4/23/12 4:34 AM, [email-masked] wrote:
> Cheers, Med
>> -----Message d'origine----- De : [email-masked]
>> [mailto:[email-masked]] De la part de Brian Haberman
>> Envoyé : vendredi 20 avril 2012 14:37 À : [email-masked];
>> [email-masked] Objet
>> : Re: [MBONED] Last Call:
>> All, Apologies for not having reviewed this document earlier, but
>> I have a fair number of comments on this approach...
>>
>>
>> * Without any supporting documentation, it is unclear how this
>> address format is supposed to be utilized. This type of specialized
>> address format is better defined in a document that *uses* the
>> format.  This allows readers to derive the complete set of
>> functionality needed to support a new address format.
>
> Med: Sure but there are plenty of documents 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
> those pointers and adopted the same approach as RFC6052: only the
> address format is defined while the usage is defined in other
> companion documents.
>
>>
>> address?  There is only one bit being used in that field and there
>> is still a bit available in the standard flags field.  Why is that
>> not being used to indicate a "translatable" multicast address?
>
> Med: We have considered the use of the remaining flag, but we
> abandoned it for the reasons documented in:
> http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-01#appendix-A.1:
>
>  " It was tempting to use the remaining flag to indicate whether an
> IPv6 address embeds an IPv4 address or not.  This choice has been
> abandoned by the authors for various reasons: o  ff3x::/32 is defined
> as SSM.  Defining a new flag would require standards and
> implementations to also treat ffbx::/32 as SSM. o  Prefixes starting
> with ff7x are defined as embedded-RP, but not prefixes starting with
> fffx.  Below is provided an excerpt from [RFC3956]: " ...the encoding
> and the protocol mode used when the two high- order bits in "flgs"
> are set to 11 ("fff0::/12") is intentionally unspecified until such
> time that the highest- order bit is defined.  Without further IETF
> specification, implementations SHOULD NOT treat the fff0::/12 range
> as Embedded-RP." as such defining a new flag would require
> implementations to also treat ff7x::/12 as embedded-RP prefix. o
> This is the last remaining flag and at this stage we are not sure
> (1) Belong to ff3x::/32 and be compatible with unicast-based prefix
> [RFC3306] for SSM.  Note that [RFC3306] suggests to set "plen" to 0
> and "network-prefix" to 0. (2) Be compatible with embedded-RP
> [RFC3956] and unicast-based prefix [RFC3306] for ASM; (3) Avoid
> ff3x::4000:0001-ff3x::7fff:ffff which is reserved for IANA. Meeting
> (1) and (2) with the same location of the M-bit is not feasible
> without modifying embedded-RP and unicast-based prefix
> one for the SSM (Section 4). "
>

No, it doesn't.  As I responded to Stig earlier, I think this argument 
is specious.  I cannot condone changing an addressing architecture to 
address bugs in someone's implementation.  The statement that FF3x::/32 
is the only SSM range is not supported in RFC 3306.

> specified in [RFC3956] if embedded-RP is used.  The default value is
> all zeros.

It would help to give an example of what type of local policy would set 
this field.

>
>>
>> * The use of IPv4 multicast addresses in the lowest 32-bits of the
>> IPv6 address needs to be reconciled with the multicast allocation
>> guidelines in RFC 3307.  Specifically, using IPv4 multicast
>> addresses (0xE0000000 to 0xEFFFFFFF) overlaps with the range of
>> IPv6 addresses reserved for dynamically generated addresses, which
>> requires the T bit to be set in the prefix.
>

I am curious if any of the authors actually read RFC 3307...

>> sufficient?  The 'M' bit can be defined within the existing flags,
>> the sub-group-id can overlay the network prefix, and any additional
>> bits needed can overlay the reserved field. This eliminates the
>> need for any type of varying format based on whether the address in
>> question is ASM or SSM.
>>

Given what I stated above, I believe my proposed address layout is 
easier to maintain, conforms to the existing IPv6 addressing 
architecture, and makes processing the address easier since you are not 
looking for the M flag in different locations.

Regards,
Brian

---

From: <[email-masked]>
Date: Mon, 23 Apr 2012 14:55:48 +0200

Dear Brian,

As you can see in http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-format-00, our first approach was to use the remaining bit to indicate an IPv4 address is embedded. We abandoned that design because of the comments received during the life of this document. These comments make sense to me, in particular the compatibility with existing implementations and the potential conflict with RFC3956. 

As a consequence of this design choice, two prefixes are (to be) reserved for 4/6 interconnection purposes: 

   o  ff3x:0:8000/33 for SSM
   o  ffxx:8000/17 for ASM

FWIW, this address format has been implemented by at least two vendors and I didn't received any comment saying that dealing with two prefixes is complex. 

I'm not convinced there are strong arguments to roll-back to the initial design but as an editor of the document I'm open to guidance from the WG.

Cheers,
Med 

>De : Brian Haberman [mailto:[email-masked]] 
>Envoyé : lundi 23 avril 2012 14:24
>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : [email-masked];

---

From: Brian Haberman <[email-masked]>
Date: Mon, 23 Apr 2012 09:47:57 -0400

On 4/23/12 8:55 AM, [email-masked] wrote:
> Dear Brian,
>
> As you can see in
> http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-format-00,
> our first approach was to use the remaining bit to indicate an IPv4
> address is embedded. We abandoned that design because of the comments
> received during the life of this document. These comments make sense
> to me, in particular the compatibility with existing implementations
> and the potential conflict with RFC3956.

I did a brief scan of the mboned mailing list and did not see a comment 
that would have led to this change.  Can you send me an archive link for 
those comments?

>
> As a consequence of this design choice, two prefixes are (to be)
> reserved for 4/6 interconnection purposes:
>
> o  ff3x:0:8000/33 for SSM o  ffxx:8000/17 for ASM
>
> FWIW, this address format has been implemented by at least two
> vendors and I didn't received any comment saying that dealing with
> two prefixes is complex.
>

I did see one comment on the mailing list about having an open-source 
implementation using the -00 version of the individual draft.  Has that 
implementation been changed?  Did they have any issues with 
functionality based on the original design of using the last bit in the 
existing flags field?

I also have a procedural question.  What was this work not done in 6MAN? 
  Since you are updating 4291 (IPv6 Addressing Architecture), it is in 
their area of expertise.  Quoting their charter:

   The 6man working group is responsible for the maintenance, upkeep,
   and advancement of the IPv6 protocol specifications and addressing
   architecture.

The only involvement they received was a forwarded notice of the mboned 
WGLC message.

Regards,
Brian

---

From: <[email-masked]>
Date: Mon, 23 Apr 2012 16:14:58 +0200

Re-,

Please see inline.

Cheers,
Med 

>Envoyé : lundi 23 avril 2012 15:48

Med: Attached some comments I received from P. Savola, Stig, Jacni and Behcet. 

>functionality based on the original design of using the last 

Med: The implementations I'm talking about are those demoed here: http://www.internetsociety.org/articles/demonstrating-ipv4-multicast-service-continuity-during-ipv6-migration.

>I also have a procedural question.  What was this work not 

Med: We first submitted this work to BEHAVE as a natural place because RFC6052 was developed there (and not 6man). Then, during the discussion regarding multrans initiative, R. Bonica kindly suggested mboned hosts this work.  

>The only involvement they received was a forwarded notice of 

Med: Yes. This document was LCed in 6man and v6ops for 2 weeks. I didn't received any comment from 6man and v6ops.

>Brian

Subject: Re: IPv4-embedded IPv6 multicast address
From: Pekka Savola <[email-masked]>
To: BOUCADAIR Mohamed OLNC/NAD/TIP <[email-masked]>
Date: Wed, 19 Jan 2011 12:53:02 +0100

On Wed, 19 Jan 2011, [email-masked] wrote:
> We have edited recently an I-D 
> (http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-format-00) 
> to specify the format of a multicast IPv6 address embedding an IPv4 
> address. These addresses are used in the context of IPv4-IPv6 multicast 
> interconnection (both encap and translation schemes have been proposed).
...
> Do you have any thoughts about this? what is the option you would recommend?

I skimmed the document briefly and I don't quite understand why you need 
the bit to begin with; it's fine to embed v4 addresses inside v6 in any 
way that you want (that is compliant with addressing architecture, that 
is).  My assumption therefore is that someone is proposing a solution 
where the information "there's a v4 address inside, and we've specified 
that it MUST be HERE" needs to be conveyed outside the operator who chose 
the prefix.  I'm not quite sure why.

But that aside..

Given that the usage of the bit seems orthogonal to R|P|T|-flags (or 
bits) and there is just one bit left in that position, my first reaction 
would be that using rsvd field would be the best bet.

Or even, if you expect using only 1 bit, it might not even be problematic 
to re-use the highest order bit of RIID.  Even when RFC3956 is used, that 
would still leave 8 values for the RP identification. (But it could 
already be in use, so it could be a bit ambiguous and would unnecessarily 
overload the address patterns.)

Pekka Savola

Subject: Re: Preparing the 01 version of 64 multicast address format I-D
From: Stig Venaas <[email-masked]>
To: BOUCADAIR Mohamed OLNC/NAD/TIP <[email-masked]>
Cc: Jacni Qin <[email-masked]>, "[email-masked]" <[email-masked]>, Xing Li <[email-masked]>, "Lee, Yiu" <[email-masked]>
Date: Wed, 19 Jan 2011 20:45:00 +0100

On 1/18/2011 11:26 PM, [email-masked] wrote:
> Hi Jacni,
> Thank you for your feedback.
> This makes sense to me. I need to hear more opinions before removing
> option 1 from the draft and maintain only the second option.
> In any case, we need to record why we removed the first option.

I have some comments below. I will also send you some additional
editorial comments on the draft soon. But maybe good to discuss
the more high level things first.

> Cheers,
> Med
>
> ------------------------------------------------------------------------
> *De :* Jacni Qin [mailto:[email-masked]]
> *Envoyé :* mardi 18 janvier 2011 17:32
> *À :* BOUCADAIR Mohamed OLNC/NAD/TIP
> *Cc :* [email-masked]; Xing Li; Stig Venaas; Lee, Yiu
> *Objet :* Re: Preparing the 01 version of 64 multicast address format I-D
>
> Dear Med, all,
>
> Please see below,
>
> On Tue, Jan 18, 2011 at 10:45 PM, <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Dear all,
>     Thank you all for your interest to this I-D.
>     Please find attached the xml file to be used for preparing the next
>     version of the draft.
>     Some open issues are listed below; your thoughts are welcome:
>     * The use of M-bit and the potential conflict with the SSM Mode
>
>
> Jacni>:Setting the M-bit before R-bit will result in reserving a new
> FFBX::/32 block for SSM, which may conflict with RFC4607. So I propose
> to use one of the 4 bits between "Scope" and "RIID", a block is still
> needed but can fall in the FF3X::/32.

I agree that should not set the M-bit as specified in the drafts. As
you say, it causes problems for SSM. I also think there are embedded-RP
implementations that assume the flag field to have the value 7, and not
allowing F. Also, there is only one flag available, and I don't think
it should be used unless we have a very good purpose. There might be a
better need for that flag in the future.

I agree it would be better to put any flags right after scope.

See below for some of my thoughts on this. I hope they make some sense :)

>
>     * Maintain the S-bit or remove it: the argument would be to
>     configure two distinct IPv4-embedded IPv6 multicast addresses
>     instead of carrying the information in the address itself.
>
>
> Jacni>:I suggest we remove the S-bit, since the argument makes sence.
> :-) This should be left to operators and achieved by deployments.
>
>     * Complete the SSM section; Xing has suggested to complete this section.
>
>
> Jacni>:We have to settle the M-bit first before working on this section.

My main question about having such bits and the prefixes in general, is
whether they need to be well-known prefixes or follow a well-known
scheme. I think it may make sense, but let me try to explain.

For some deployments it could work for say an ISP to decide on their own
/96 IPv6 multicast prefix (it could be based on their unicast-address or
embedded-RP), they could use SAP or some other way to tell devices which
IPv6 groups they should join, based on that prefix. They then configure
a translator device with this prefix so that it knows what to do.

I think for this draft, it would be good to explain why it makes sense
to standardize something. I think I can come up with some reasons also.

If we reserve well-known prefixes, we need to minimum reserve one
prefix for SSM and one for ASM. If some kind of flags are needed, then
there is the choice if defining those flags separately, or make them
part of the prefix and define multiple SSM and ASM prefixes if you get
my meaning. The bits on the wire are the same, it's just whether the
flag is part of the prefix definition itself or not.

For SSM, based on RFC 3307, it should be FF3x::/96. But in RFC 4607 it
says that FF3x::/32 is SSM, so we can basically define a well-known
prefix which is 33-96 bits long.

If we want a well-known prefix that is compatible with embedded-RP,
then I think it needs to use some of the reserved bits, but leave
the bits after unspecified. So the length should be at most 24 bits.
In order to not waste too many of the reserved bits, it should be as
short as possible... You are suggesting 20 bits with the scheme which
perhaps is fine.

With just 17 bits, we could say that FFxx:8000::/17 is to be used for
ASM and that the last 32 bits are the IPv4 address. I think it is a
good idea to have the possibility for a few flags though, such as your
scheme bits. So I would suggest something like:

|   8    |  4 |  4 |  4 |             76               |    32    |
+--------+----+----+----+------------------------------+----------+
|11111111|flgs|scop|1res|         sub-group-id         |v4 address|
+--------+----+----+----+------------------------------+----------+

Basically the first bit in the field "1res" means that there is an
embedded IPv4 multicast address. The rest of the bits can be reserved
for future purposes. Or they could contain things like the S-bit if
we think we know we need it at this point.

For SSM I think it should be:

|   8    |  4 |  4 |    8   |  4 |       76         |    32    |
+--------+----+----+--------+----+------------------+----------+
|11111111|flgs|scop|00000000|1res|   sub-group-id   |v4 address|
+--------+----+----+--------+----+------------------+----------+

The meaning of "1res" should probably be the same as the same
field for ASM?

One problem I see with having optional bits may make some uses
harder. If there are no optional bits, then a device/application
that sees just an IPv4 address may know exactly how to construct
the IPv6 address. With optional bits (like scheme), it may not be
known to the device/application what those bits should be set to.

Any thoughts?

Stig

> Cheers,
> Jacni
>
>     * Add some requirements such as the use of the same algorithm and
>     prefix in the client side and the IPv4-IPv6 interconnection function.
>     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.
>     ********************************
>
>
> *********************************
> 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.
> ********************************

Subject: Re: OFFLIST Re: [BEHAVE] Multicast IPv4-embedded Address Format
From: Behcet Sarikaya <[email-masked]>
To: BOUCADAIR Mohamed OLNC/NAD/TIP <[email-masked]>
Date: Thu, 6 Jan 2011 21:27:29 +0100

Bonjour Med,
  Merci de ta reponse.
Il y a un problem avec le M bit. Tel que defini dans la draft, il est impossible de former des adresses SSM avec le SSM prefix FF3x::/96 qui est habituellement utilise.
J'ai trouve le "S" bit qui doit etre "1" pour translation aussi difficile a utiliser: ca donne des prefix comme FF7X1:: pour SSM.

Il est difficile de jouer avec les adresse multicast.

A+

Behcet

---

From: Stig Venaas <[email-masked]>
Date: Tue, 24 Apr 2012 10:16:42 -0700

I am open for using the flag bit Brian suggests, but we need to see what
the rest of the community thinks. And that probably should be discussed
in both mboned and 6man.

If we go for the one remaining flag bit, which I agree is a possibility,
it will have some consequences:

1. No more flag bits left, do we need more in the future?
2. Some of the current RFCs need to be updated. E.g. 3306, 4607 and
    3956. Also some implementations need to be updated.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Fri, 20 Apr 2012 09:58:50 -0700

On 4/20/2012 5:36 AM, Brian Haberman wrote:
> All,
> Apologies for not having reviewed this document earlier, but I have a
> fair number of comments on this approach...
>
>

Stig

> in RFC 3307. Specifically, using IPv4 multicast addresses (0xE0000000 to
> 0xEFFFFFFF) overlaps with the range of IPv6 addresses reserved for

---

From: SM <[email-masked]>
Date: Sat, 21 Apr 2012 16:26:23 -0700

>[email-masked] mailing lists by 2012-05-02. Exceptionally, comments may be

Is there a write-up for this proposal?

In Section 2:

   "The format to build such addresses is defined in Section 3 for
    ASM mode and Section 4 for SSM mode."

I suggest expanding ASM and SSM on first use.

In Section 3:

   "To meet the requirements listed in Appendix A.2"

Wouldn't it be better to reference RFC 4291?

   "This field must follow the recommendations specified in [RFC3306]
    if unicast-based prefix is used or the recommendations specified
    in [RFC3956] if embedded-RP is used."

Shouldn't that be a MUST?

In Section 4:

   "Flags must be set to 0011."

Is that a requirement?

   "The embedded IPv4 address SHOULD be in the 232/8 range [RFC4607].
    232.0.0.1-232.0.0.255 range is being reserved to IANA."

Why is this a SHOULD?  What does being reserved to IANA mean?

Although the proposal appears simple, I would suggest further review 
as it updates RFC 4291.

Regards,
-sm

---

From: <[email-masked]>
Date: Wed, 25 Apr 2012 17:05:23 +0200

Dear SM,

Thank you for the review. 

Please see inline.

Cheers,
Med 

>De la part de SM
>Envoyé : dimanche 22 avril 2012 01:26
>À : [email-masked]
>Cc : [email-masked]
>(IPv4-Embedded IPv6 Multicast Address Format) to Proposed Standard
>

Med: Ok. Done in my local copy. Thanks.

>Wouldn't it be better to reference RFC 4291?

Med: Do you mean, cite RFC4291 in addition to the ref to Appendix A.2?

>Shouldn't that be a MUST?

Med: Done. 

>   "Flags must be set to 0011."

Med: Yes, because as listed in Appendix A.2, we wanted to have an a prefix in the ff3x::/32 range.

>Why is this a SHOULD? 

Med: We first considered a "MUST" but we relaxed that required to "SHOULD" for any future use case which may need to map IPv4 ASM to IPv6 SSM. Does this makes sense to you?

 What does being reserved to IANA mean?

Med: It should be "for IANA allocation" instead of "to IANA". Better?

>Although the proposal appears simple, I would suggest further review 

Med: Reviews are more than welcome. FWIW, a call for review has been issued in 6man and 6vops for 2 weeks:
* http://www.ietf.org/mail-archive/web/ipv6/current/msg15488.html
* http://www.ietf.org/mail-archive/web/v6ops/current/msg12174.html

---

From: SM <[email-masked]>
Date: Wed, 25 Apr 2012 11:22:29 -0700

Hi Med,
>Med: Do you mean, cite RFC4291 in addition to the ref to Appendix A.2?

Yes, and have Appendix A.2 as informative.

>prefix in the ff3x::/32 range.

You are using a "must".  It might be interpreted differently.

>Med: We first considered a "MUST" but we relaxed that required to 
>"SHOULD" for any future use case which may need to map IPv4 ASM to 
>IPv6 SSM. Does this makes sense to you?

Yes.

>Med: It should be "for IANA allocation" instead of "to IANA". Better?

There is no mention of that in the IANA Considerations section.  The 
range is already reserved for SSM destination addresses.  I am at a 
lost on that part of the text.  I'll defer to you on this.

Well, you tried your best.

Regards,
-sm

---

From: Jacni Qin <[email-masked]>
Date: Thu, 26 Apr 2012 23:32:05 +0800

Hi SM,

Thanks a lot for your review, and please see below.

On Thu, Apr 26, 2012 at 2:22 AM, SM <[email-masked]> wrote:

> Maybe adding a quick explanation following it will make it better?

>> "SHOULD" for any future use case which may need to map IPv4 ASM to IPv6
>> SSM. Does this makes sense to you?
>>
>
> Yes.
>
>
> There is no mention of that in the IANA Considerations section.  The range
> is already reserved for SSM destination addresses.

Right, that's why we think there is no need to mention that again. Sorry,
I'm a little confused. or I misunderstood what you mean? ;-)

Cheers,
Jacni

> I am at a lost on that part of the text.  I'll defer to you on this.
>
> ______________________________**_________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mboned<https://www.ietf.org/mailman/listinfo/mboned>
>

---

From: SM <[email-masked]>
Date: Thu, 26 Apr 2012 15:40:23 -0700

Hi Jacni,

Thanks for the feedback.

>Maybe adding a quick explanation following it will make it better?

If it's a requirement, you could use "MUST".   You are using the RFC 
2119 key words in the previous and following bullet points to specify 
the requirements.

>Right, that's why we think there is no need to mention that again. 
>Sorry, I'm a little confused. or I misunderstood what you mean? ;-)

If one reads the text, it's not clear whether the range is being 
reserved or not.

BTW, Med followed up on this.

Regards,
-sm