Subject: [MBONED] draft-ietf-mboned-64-multicast-address-format-03.txt

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 13 Aug 2012 15:21:26 -0500

Hi authors,

Thanks for the revised draft, I find that the revision is in the right
direction.

I am confused on the prefix lengths:
on Figure 2,
ffxx:8000:0:abc::/96
while in Section 3.1
ffxx:8000::/20

How come these are reserved prefixes?
What are the values that are reserved?

If you look at RFC 6052, the unicast translation specification,
64:ff9b::/96 is defined as the Well-Known Prefix. There are no x's in
the prefix definition.

Regards,

Behcet

On Fri, Aug 10, 2012 at 1:49 AM,  <[email-masked]> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the MBONE Deployment Working Group of the IETF.
>
>         Title           : IPv6 Multicast Address With Embedded IPv4 Multicast Address
>         Author(s)       : Mohamed Boucadair
>                           Jacni Qin
>                           Yiu L. Lee
>                           Stig Venaas
>                           Xing Li
>                           Mingwei Xu
>         Filename        : draft-ietf-mboned-64-multicast-address-format-03.txt
>         Pages           : 13
>         Date            : 2012-08-09
>
> Abstract:
>    This document reserves two IPv6 multicast prefixes to be used in the
>    context of IPv4-IPv6 interconnection.  The document specifies an
>    algorithmic translation of an IPv6 multicast address to a
>    corresponding IPv4 multicast address, and vice versa.  This
>    algorithmic translation can be used in both IPv4-IPv6 translation or
>    encapsulation schemes.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-mboned-64-multicast-address-format
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-03
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-mboned-64-multicast-address-format-03
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

---

From: Brian Haberman <[email-masked]>
Date: Mon, 13 Aug 2012 17:46:33 -0400

> I am confused on the prefix lengths:

The x's correspond to the flags and scope fields within the multicast 
address.  Take a look at:

http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xml#ipv6-multicast-addresses-4

---

From: Stig Venaas <[email-masked]>
Date: Mon, 13 Aug 2012 16:18:22 -0700

> http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xml#ipv6-multicast-addresses-4

We have one minor issue here though. They cannot simply be IANA
allocations, since they would not have the transient bit set. In
this case, the idea is that it should work for flag nibble values
like 1, 3 and 7. Actually I believe the transient bit should always
be set for these groups.

Stig

>>>          Filename        :
>>> draft-ietf-mboned-64-multicast-address-format-03.txt
>>>          Pages           : 13
>>>          Date            : 2012-08-09
>>>
>>> Abstract:

---

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

Hi Behcet, all,

I was planning to send an e-mail to the list to notify the main changes we implemented in -03. Since you started this thread, I will use it for that purpose. 

The main changes are as follows:

* Abandon the M-bit idea

* 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

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

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

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] 
>De la part de Behcet Sarikaya
>Envoyé : lundi 13 août 2012 22:21
>À : MBONED WG
>Objet : [MBONED] draft-ietf-mboned-64-multicast-address-format-03.txt
>
>Hi authors,
>

---

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

> like 1, 3 and 7. Actually I believe the transient bit should always

I think it will be better to clarify in the draft saying that xx
corresponds to flgs and scop fields defined in RFC 3306.

Regards,

Behcet

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 14 Aug 2012 21:43:36 +0000

Hi Stig,

Since we want T=1, this will not meet the "well-known" requirement defined
in RFC4291. If we don't want to define a flag, what is the proper way to
describe ffxx:8000::/20 and ffxx:0:8000::/96?

Thanks,
Yiu

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 14 Aug 2012 21:44:13 +0000

Hi Behcet,

Note taken. Thanks!

---

From: Brian Haberman <[email-masked]>
Date: Tue, 14 Aug 2012 17:47:47 -0400

Why does T need to be 1?

Brian

---

From: Stig Venaas <[email-masked]>
Date: Tue, 14 Aug 2012 18:33:19 -0700

> Why does T need to be 1?

First of all, the idea is that it should work for SSM,
Embedded-RP and Prefix-based addresses. All of which have
T=1.

Also, it's not exactly like each address is allocated by
IANA for a specific purpose. I think it is correct to think
of these addresses as transient by nature.

Stig

>>>> http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-a
>>>>
>>>> ddresses.xml#ipv6-multicast-addresses-4
>>>
>>>>>>      algorithmic translation can be used in both IPv4-IPv6
>>>>>> translation
>>>>>> or
>>>>>>      encapsulation schemes.
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-mboned-64-multicast-address
>>>>>>
>>>>>> -format
>>>>>>
>>>>>>
>>>>>> http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-forma
>>>>>>
>>>>>> t-03
>>>>>>
>>>>>>
>>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-mboned-64-multicast-address
>>>>>>
>>>>>> -format-03
>>>>>>
>>>>>>
>>>>>>

---

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

> describe ffxx:8000::/20 and ffxx:0:8000::/96?

You could list them for all values of xx perhaps. I would maybe use
"x" and "y" and then discuss the allowed values.

There are scope relative allocations today, the main thing is that we
don't want to require the flags to be "0". Or maybe we want to require
the T-bit to be set. As I wrote earlier, I would think of these
addresses as transient, and T=1 is required for Embedded-RP etc.

The issue though is that if T=1, then it is not really an IANA
allocation as I see it, because IANA allocations have T=0. But if there
is IETF consensus, then one can still reserve these prefixes.

Stig

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 15 Aug 2012 13:05:11 +0000

I like the idea to use x and y and explain the flag and scope in the
draft. As you said, we want to be flexible to support T=1, so this is not
a typical IANA allocation. If we get WG census to move forward, then we
can decide how to reserve these prefixes.

On 8/14/12 9:43 PM, "Stig Venaas" <[email-masked]> wrote:

>>>>>>    This draft is a work item of the MBONE Deployment Working Group
>>>>>>of
>>>>>> the IETF.
>>>>>>
>>>>>>           Title           : IPv6 Multicast Address With Embedded
>>>>>>IPv4
>>>>>> Multicast Address
>>>>>>      This document reserves two IPv6 multicast prefixes to be used
>>>>>>in
>>>>>> the

---

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

Hi Behcet,

I updated my local copy to take into account your comment. Thanks.

Cheers,
Med 

>Envoyé : mardi 14 août 2012 18:55
>À : Stig Venaas
>Cc : [email-masked]
>Objet : Re: [MBONED] 
>http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-m
>ulticast-addresses.xml#ipv6-multicast-addresses-4
>>
>>
>>>>>   This draft is a work item of the MBONE Deployment 
>Working Group of
>>>>> the IETF.
>>>>>
>>>>>          Title           : IPv6 Multicast Address With 
>Embedded IPv4
>>>>> Multicast Address
>translation or

---

From: Tim Chown <[email-masked]>
Date: Fri, 17 Aug 2012 00:12:01 +0100

> is IETF consensus, then one can still reserve these prefixes.

I agree with Stig; there are multiple prefixes being reserved here.

The text is effectively updating both RFC3306 and RFC3956 since the above prefix is setting a bit in the reserved bit range of both those specifications.  RFC3306 also says all those reserved bits (17-24) must be zero, while RFC3956 doesn't explicitly say that for bits 17-20 (it probably should, if you're now using one of those bits).

Both RFCs say that if R or P flags are set, then T must be set too, so I'm not sure you have freedom to say "if T=1" if you want to support those two methods. 

Finally, it may make more sense to use ffxx:1000::/20 for ASM, and thus only use the rightmost bit of the four reserved bits (for RFC3956 at least)?

Tim

---

From: Stig Venaas <[email-masked]>
Date: Fri, 17 Aug 2012 11:06:17 -0700

Hi Tim

> The text is effectively updating both RFC3306 and RFC3956 since the above prefix is setting a bit in the reserved bit range of both those specifications.  RFC3306 also says all those reserved bits…

You're right about 3306. I wonder now if instead of practically
reserving a specific value for the entire nibble of remaining
reserved bits in 3306, it would be better to reserve just one of
the bits. I don't think it updates 3956, because it doesn't talk
about those bits at all, AFAICT.

> Both RFCs say that if R or P flags are set, then T must be set too, so I'm not sure you have freedom to say "if T=1" if you want to support those two methods.

Yes, that's why I've been saying that we can't just get an IANA
allocation. We need T=1 for this to work, and IANA is allocating
ASM with T=0.

> Finally, it may make more sense to use ffxx:1000::/20 for ASM, and thus only use the rightmost bit of the four reserved bits (for RFC3956 at least)?

Yes, but it would mean that if in the future one wants to use a
new reserved bit for another purpose, then it won't work for
this purpose. I like the idea of using a single bit actually.

So here is an alternative proposal. Do you think it's better?

1. Update 3306 and give a new meaning to one of the remaining
    reserved bits.

2. Get a /96 for ASM from IANA (which would have T=0).

The first would allow for 3306 and 3956 addressing, which I
think is useful.

The second would allow for uses where people don't care for
that other type of addressing, and may also be useful if you
want to use more or less fixed addresses, that does not use
any particular unicast address.

The alternative of just getting a /96 for ASM from IANA is
in draft-kumar-mboned-64mcast-wkp-address-00.txt.

I guess just doing IANA assignments and reserving a bit
from 3306 are slightly separate problems, with different
issues and uses.

Finally, we also need a /96 for SSM. That can't just be
an IANA assignment either. One interesting thing here is
maybe that SSM is based on 3306 with plen and prefix set
to 0. So if a bit is reserved (from 3306), then I think
it would technically apply to SSM as well. But the SSM
implementations I've seen (as well as a couple of RFCs)
assume that these reserved bits are all 0. Not ignored
as they should have been...

Stig

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 17 Aug 2012 14:20:59 -0500

On Fri, Aug 17, 2012 at 1:06 PM, Stig Venaas <[email-masked]> wrote:
>> The text is effectively updating both RFC3306 and RFC3956 since the above
>> prefix is setting a bit in the reserved bit range of both those
>> specifications.  RFC3306 also says all those reserved bits (17-24) must be
>> zero, while RFC3956 doesn't explicitly say that for bits 17-20 (it probably
>> should, if you're now using one of those bits).
>
>
>> Both RFCs say that if R or P flags are set, then T must be set too, so I'm
>> not sure you have freedom to say "if T=1" if you want to support those two
>> methods.
>
>
>> Finally, it may make more sense to use ffxx:1000::/20 for ASM, and thus
>> only use the rightmost bit of the four reserved bits (for RFC3956 at least)?
>
>

We just wanted to define two reserved multicast IPv6 prefixes and
after giving up modifying IP addressing architecture, we are now
talking about changing so many RFCs.

In this mail earlier Stig said:

http://www.ietf.org/mail-archive/web/mboned/current/msg01663.html

we can state that inter-domain operation is not a requirement and we
do not support embedded-RP.

Behcet

---

From: Stig Venaas <[email-masked]>
Date: Fri, 17 Aug 2012 12:50:31 -0700

> do not support embedded-RP.

I wrote something slightly different:

"Of course we could argue whether we need to support embedded-RP.
It is very useful, especially inter-domain, but if that is not a
requirement, we may not need to support it."

I left it open to discussion. I'm trying to get all the options on the
table here.

Alternative 2 above is sufficient if we don't care about embedded-RP,
and is in draft-kumar-mboned-64mcast-wkp-address-00.txt.

But I do see value in both unicast-prefix based addressing (a good
way to ensure your addresses are unique), and embedded-RP (which is
necessary inter-domain, but may at times be used intra-domain). And I
do know deployments using inter-domain embedded-RP.

If we want to support unicast-prefix based addressing or
embedded-RP, it appears we need to update RFC 3306.

Note that we would not change 3306 in any way. We only need
this draft to say that it Updates 3306.

Stig

---

From: <[email-masked]>
Date: Mon, 20 Aug 2012 07:58:29 +0200

Hi Behcet,

There is a real value to ensure compatibility with unicast based and embedded-RP for ASM. As pointed by T. Chown this would require to update rfc3306 but I don't think this is problematic.

Now for Stig's Idea to reserve an additional /96 prefix (for ASM, T=0), we need more feedback from the WG.

Cheers,
Med

>Envoyé : vendredi 17 août 2012 21:21
>À : Stig Venaas
>Cc : [email-masked]
>Objet : Re: [MBONED]

---

From: Jacni Qin <[email-masked]>
Date: Mon, 20 Aug 2012 17:29:18 +0800

hi,

On 8/18/2012 Saturday 2:06 AM, Stig Venaas wrote:
>> The text is effectively updating both RFC3306 and RFC3956 since the
>> above prefix is setting a bit in the reserved bit range of both those
>> specifications. RFC3306 also says all those reserved bits (17-24)
>> must be zero, while RFC3956 doesn't explicitly say that for bits
>> 17-20 (it probably should, if you're now using one of those bits).
>
>> Both RFCs say that if R or P flags are set, then T must be set too,
>> so I'm not sure you have freedom to say "if T=1" if you want to
>> support those two methods.
>
>> Finally, it may make more sense to use ffxx:1000::/20 for ASM, and
>> thus only use the rightmost bit of the four reserved bits (for
>> RFC3956 at least)?
>

Sounds good, and it works for SSM, ASM with unicast-based prefix feature
and ASM with embedded-rp feature.

> it would technically apply to SSM as well. 
Sorry, I'm a little confused here. If 1 bit approach works, why do we
need a /96 for SSM? Did I miss anything?

Cheers,
Jacni

> But the SSM
> .

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 20 Aug 2012 14:49:42 -0500

> requirement, we may not need to support it."

Embedded-RP prefix is FF7e, so FFxx supports it.

> this draft to say that it Updates 3306.

Why?
As far as I understand, the issue here is to use which bit in the
reserved field, Tim suggested the rightmost and your proposal uses the
leftmost.
RFC3946 solves this problem by redefining rsvd field as 4 bits instead
of 8 bits in RFC 3306, i.e. it updates 3306 which is already stated in
there.

Maybe in this draft we can say that we use RFC 3946 definition of the
reserved field.

BTW, in Teemu Kiviniemi's thesis on Implementation of an IPv4 to IPv6 Multicast
Translator
ASM prefix: ff7e:140:2001:db8:ab:cd::/96
is used, which matches Tim's suggestion :-).

This is the SSM prefix: ff3e::/96 that is used.

Behcet

---

From: Tim Chown <[email-masked]>
Date: Mon, 20 Aug 2012 23:39:00 +0100

> Embedded-RP prefix is FF7e, so FFxx supports it.

Well, it uses ff7x.  We use embedded RP intra-domain on our campus, not just inter-domain.

> of 8 bits in RFC 3306, i.e. it updates 3306 which is already stated in

Can't we just say 3306 is updated by this new text, if it is approved?  We may not need to change 3306.

I think the same applies to RFcC3956 too, as bits 17-20 are reserved, and you're using those.  Actually also nteresting to read Appendix A of that RFC ;)

> is used, which matches Tim's suggestion :-).

Not quite, the above is ff7e:0140....
> This is the SSM prefix: ff3e::/96 that is used.

BTW, Stig had a v4/v6 multicast translator runnng ten years ago, worked quite well!

Cheers,
Tim

---

From: Jacni Qin <[email-masked]>
Date: Tue, 21 Aug 2012 10:42:13 +0800

Hi Tim,

On 8/21/2012 Tuesday 6:39 AM, Tim Chown wrote:
> ..
Agree.

> I think the same applies to RFcC3956 too, as bits 17-20 are reserved, and you're using those.  Actually also nteresting to read Appendix A of that RFC ;)
I guess we won't need a "RFC3956 updated", since Appendix A just says, "

    Instead of using flags bits ("FF70::/12"), one could have used the
    leftmost reserved bits instead ("FF3x:8000::/17").
"

and doesn't say anything about the 4bit rsvd elsewhere.

Or I misunderstand it?

Cheers,
Jacni

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 21 Aug 2012 10:55:43 -0500

Hi Tim,

> I think the same applies to RFcC3956 too, as bits 17-20 are reserved, and you're using those.  Actually also nteresting to read Appendix A of that RFC ;)

Yes, I read. Maybe you missed my point: if we use RFC 3956 and state
it clearly, updating RFC 3306 is going to be implicit in this
normative use.

> Not quite, the above is ff7e:0140....

Sorry, I confused the bits.
But the above address seemed to have worked as well. I think that is
the point here.

>> This is the SSM prefix: ff3e::/96 that is used.

My suggestion is to define the ASM prefix as either ff70::/12 or as
ff3x:8000/17 this way we align the prefix with the embedded RP prefix.

Regards,

Behcet

---

From: Tim Chown <[email-masked]>
Date: Tue, 21 Aug 2012 17:09:15 +0100

> and doesn't say anything about the 4bit rsvd elsewhere.

I'm not sure what the proper process is here.  My point was just that RFC3956 states that bits 17-20 are reserved, but the proposed range of addresses used by this draft involves setting a bit within that range, hence we should have an "updated by" note.  Also that RFC3956, unlike RFC3306, doesn't explicitly say the reserved bits must be set to zero.  

The irony of Appendix A of RFC3956 is that it mentioned that one could have used precisely the same range of addresses for Embedded-RP as is proposed for this draft, but instead a flag bit was used.

In response to Behcet's email, I agree the update(s) is/are implicit. 

Tim

---

From: Jacni Qin <[email-masked]>
Date: Thu, 23 Aug 2012 12:07:01 +0800

On 8/22/2012 Wednesday 12:09 AM, Tim Chown wrote:
> On 21 Aug 2012, at 03:42, Jacni Qin <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Hi Tim,
>>
> I'm not sure what the proper process is here.  My point was just that 
> RFC3956 states that bits 17-20 are reserved,
The 3956 doesn't really make that statement on the 4 bits itself, 
instead, more like inheriting from 3306.
While I don't think this issue matters that much technically, we can 
follow a proper process if anyone have one.

> but the proposed range of addresses used by this draft involves 
> setting a bit within that range, hence we should have an "updated by" 
> note.  Also that RFC3956, unlike RFC3306, doesn't explicitly say the 
> reserved bits must be set to zero.
>
> The irony of Appendix A of RFC3956 is that it mentioned that one could 
> have used precisely the same range of addresses for Embedded-RP as is 
> proposed for this draft, but instead a flag bit was used.
So, following this logic, we'll be perfectly fine using a flag. ;-)

Cheers,
Jacni

---

From: <[email-masked]>
Date: Thu, 23 Aug 2012 11:29:06 +0200

Dear Tim,

I agree with you an update note is needed to be added to the draft for 3306 and 3956. The consequence of this change, and in order to accommodate future extensions, I have changed also the text for ASM mode to reserve a bit and not a prefix. I see this as an incentive for applications to check the bit and not match a prefix.

For the SSM mode, I maintained the same /96 as in -03.

I will submit a new version with these new changes (+ other minor modifications).

Thanks.

Cheers,
Med

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Tim Chown
Envoyé : mardi 21 août 2012 18:09
À : [email-masked]
Objet : Re: [MBONED] draft-ietf-mboned-64-multicast-address-format-03.txt

On 21 Aug 2012, at 03:42, Jacni Qin <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tim,

Or I misunderstand it?

Tim