[v6ops] Multicast support [was: v6ops Digest, Vol 52, Issue 41]

[Brian E Carpenter <[e-mail]>]

On 20/12/2014 14:56, Mark ZZZ Smith wrote:
> 
>> ________________________________
>> From: Tariq Saraj <[e-mail]>
>> To: Mark ZZZ Smith <[e-mail]>; [e-mail] 
>> Sent: Saturday, 20 December 2014, 1:36
>> Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41
>>
>> Smith what you are pointing is all at link level and purely related to IPv6, Discussion is related Multicast support in Hybrid IPv4-IPv6 Internet at IP layer (i.e. IPvX-IPvY-IPvX)  
> 
>>
> 
> So the layer below the network layer is the link-layer.
> 
> IPv6 is the network layer protocol, and therefore any protocols directly below it from the IPv6 point of view are either literally or conceptually link-layer protocols.
> 
> IPv6 encapsulated in IPv4 means that IPv4 is being used as by IPv6 as a link-layer protocol, and is constructing a single link-layer link for IPv6 to operate over.
> 
> IPv6 expects link-layers to provide or emulate unicast and multicast capabilities. If IPv4 is being used to construct a link-layer for IPv6 to operate over, then it should provide or emulate a link-layer unicast and multicast capability.

This was of course exactly the basis for 6over4
(http://tools.ietf.org/html/rfc2529).
That was intended for single administrative domains, where IPv4
multicast was a not
unreasonable but rather optimistic assumption in 1999.

> 
> Once the (IPv4 constructed) link-layer provides or emulates both a unicast and multicast capability, there is nothing special about it from the IPv6 point of view, and I don't think there needs to be any IPv6-specific handling of this situation. If the link-layer IPv4 is further encapsulated in other IP encapsulations ("i.e. IPvX-IPvY-IPvX"), that is all hidden within the link-layer or below it and not visible or relevant to IPv6 operation at the network layer. Making IPv6 aware of that would be a layer violation.
> 
> 
> More broadly, what has been missing from 6to4 was the emulation of a multicast capability, meaning that 6to4 currently doesn't really meet IPv6's minimum link-layer link capability requirements. It seems some work was done on emulating it in the following draft, but it didn't advance for some reason or another:
> 
> Support for Multicast over 6to4 Networks
> https://tools.ietf.org/html/draft-thaler-ngtrans-6to4-multicast-01

14 years ago, multicast deployment was low on the list of IPv6 priorities.

   Brian

> 
> 
>>
>> On Fri, Dec 19, 2014 at 3:03 AM, Mark ZZZ Smith <[e-mail]> wrote:
>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: Gert Doering <[e-mail]>
>>>> To: Tariq Saraj <[e-mail]>
>>>> Cc: [e-mail]
>>>> Sent: Tuesday, 16 December 2014, 5:01
>>>> Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41
>>>>
>>>> Hi,
>>>>
>>>> On Sun, Dec 14, 2014 at 12:18:00AM +0500, Tariq Saraj wrote:
>>>>>  There are some issues with 6rd as well, IPv6 with all its powerful features
>>>>>  is still under critical objections in academia just because of the urgency
>>>>>  shown by IETF in standardizing protocols like 6to4 and 6rd. 6to4 clearly
>>>>>  mentioned that it cannot support multicast at layer-3, on the other end 6rd
>>>>>  claimed that multicast can be provided, my question is that while
>>>>>  standardizing 6rd which at that time was just supporting unicast traffic
>>>>>  traversing across IPv4 network and its still not matured enough to provide
>>>>>  multicast support yet in its functionality other than using some proxy
>>>>>  support for multicast traffic. why It was standardized ?
>>>>
>>>> There is no wide-area multicast anyway.
>>>
>>> Technically it should be universal, as DAD uses multicast and DAD is mandatory (except for anycast addresses), which should include tunnels.
>>>
>>> Links are supposed to provide multicast capability or emulate it to support Neighbor Discovery:
>>>
>>> RFC4861:
>>>
>>> "2.2.  Link Types
>>>
>>> Different link layers have different properties.  The ones of concern
>>> to Neighbor Discovery are:
>>>
>>> multicast capable
>>> - a link that supports a native mechanism at the link
>>> layer for sending packets to all (i.e., broadcast)
>>> or a subset of all neighbors.
>>>
>>> point-to-point - a link that connects exactly two interfaces.  A
>>> point-to-point link is assumed to have multicast
>>> capability and a link-local address.
>>>
>>> non-broadcast multi-access (NBMA)
>>> - a link to which more than two interfaces can attach,
>>> but that does not support a native form of multicast
>>> or broadcast (e.g., X.25, ATM, frame relay, etc.).
>>> Note that all link types (including NBMA) are
>>> expected to provide multicast service for
>>> applications that need it (e.g., using multicast
>>> servers).  However, it is an issue for further study
>>> whether ND should use such facilities or an
>>> alternate mechanism that provides the equivalent
>>> multicast capability for ND."
>>>
>>>
>>>
>>>>  So why bother if a closed user
>>>> group decides to deploy a stopgap technology to enable IPv6 access.
>>>>
>>>> And, when speaking about academia: do they have a "how to not write
>>>> e-mail"
>>>> class there?  Like, "take a full digest with lots of unrelated mail in it,
>>>> and write a top posting on top of it"?
>>>>
>>>> Gert Doering
>>>>         -- NetMaster
>>>> --
>>>> have you enabled IPv6 on something today...?
>>>>
>>>> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
>>>> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
>>>> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
>>>> Tel: [phone]           USt-IdNr.: DE813185279
>>>>
>>>>
>>>
>>>> _______________________________________________
>>>> v6ops mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>
>>>
>>
>>
>> -- 
>>
>> Regards
>> Tariq Saraj
>> Center for Research in Networks and Telecom (CoReNeT)
>>
>>
>>
>>
>>
>>
>>
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>