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

["Templin, Fred L" <[e-mail]>]

> -----Original Message-----
> From: v6ops [mailto:[e-mail]] On Behalf Of Brian E Carpenter
> Sent: Friday, December 19, 2014 6:58 PM
> To: Mark ZZZ Smith
> Cc: Tariq Saraj; [e-mail]
> Subject: [v6ops] Multicast support [was: v6ops Digest, Vol 52, Issue 41]
> 
> 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).

BTW, this approach is adopted also for AERO.

Thanks - Fred
[e-mail]

> 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
> >
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops