On 8/14/2012 9:40 AM, Behcet Sarikaya wrote:
On Tue, Aug 14, 2012 at 4:09 AM, <mohamed.boucad...@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, ...
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.
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
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
--------------------------------------------------------------------
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
--------------------------------------------------------------------
