Re: [v6ops] v6ops Digest, Vol 52, Issue 41

[Mark ZZZ Smith <[e-mail]>]

>________________________________
> 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.

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


>
>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)
>
>
>
>
>
>
>