Subject: 4941bis and multicast & QOS

From: Gyan Mishra <[email-masked]>
Date: Sun, 2 Feb 2020 02:26:22 -0500

How would multicast ASM or SSM work with the privacy extension temporary
address enabled.  With the privacy temporary address enabled the IGMP Join
would go out the temporary addresses, just as would normal unicast
traffic.  The temporary address would be the  RPF path shared and SPT tree.
The unidirectional multicast video stream should flow over the temporary
address.  Have the stable IID for incoming connections and temporary
address for outgoing connections I am guessing should not result in an RPF
check failure.

Has anyone tried testing multicast?

Has anyone tried setting QOS DSCP values outbound on peer to peer Cisco
Jabber voice or video flows sourced out the temporary address?

Gyan
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Sun, 2 Feb 2020 20:36:14 +0000

From: ipv6 <[email-masked]> On Behalf Of Gyan Mishra

> How would multicast ASM or SSM work with the privacy extension temporary address enabled.  With the privacy temporary address enabled the IGMP Join would go out the temporary addresses, just as would normal unicast traffic.

That's a good question, although only SSM would be a problem. In ASM, the IGMP/MLD join reports always go to the group multicast address anyway, and presumably, that won’t change. The unique source address of the client joining, or of the multicast source, should not matter. When responding to a new IGMP query, a new source address could be used in the report, still indicating to the router that membership exists. I would think, no problem.

In SSM, the IP destination address of the reports is a well-known multicast address, to routers, but of course, if you want to include only a certain set of sources, those source IP address(es) in the IGMP/MLD report either have to be valid, or you get nothing.

> The temporary address would be the  RPF path shared and SPT tree.

Isn’t this just related to multicast routing, between routers? Their addresses would not change at a dizzying rate?

Bert

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 13 Feb 2020 19:52:28 -0500

Sorry Bert I missed your reply - responding now

On Sun, Feb 2, 2020 at 3:36 PM Manfredi (US), Albert E <
[email-masked]> wrote:

> would go out the temporary addresses, just as would normal unicast traffic.
>
> That's a good question, although only SSM would be a problem. In ASM, the
> IGMP/MLD join reports always go to the group multicast address anyway, and
> presumably, that won’t change. The unique source address of the client
> joining, or of the multicast source, should not matter. When responding to
> a new IGMP query, a new source address could be used in the report, still
> indicating to the router that membership exists. I would think, no problem.
>

   You make a good point as to where the problem may fall.  So with ASM
model the receiver is not source aware and so sends a IGMP join via
temporary address RPF interface for outgoing “client like” unicast
connections.  The LHR DR on the subnet creates MRIB state and forwards *,G
shared tree join along RPF path to the Anycast RP /MSDP - which has active
SA cache entry for the Source within the multicast routing domain.  The LHR
now learns the SA for the group and initiates SPT switchover to the SPT
tree and builds a tree directly to the source.

With SSM the receiver is source aware via MLDv2, which now has source field
in the packet for the SSM channel - along with well know default SSM group
232/8 - receiver is able to send via temporary address S,G join and to its
LHR DR router on the subnet - which now builds SPT tree directly to the
source.

So this all works well in a client / server multicast model with pim
sparse-mode where the clients are receiver only and the server is source
only.

In a peer2peer multicast model where the source acts as both receiver and
source and the receiver acts as both receiver and source is the “bi-dir
PIM” model -  this is the MPLS MVPN world translates into MP2MP LMDT
instantiated via mLDP.

Multicast is predominately used in enterprises.  The internet MBONE never
really took off due to multicast use of UDP RTP  transport for streaming
and thus a requirement for end to end QOS for reliability.

So in the enterprise bi-dir pim model application requiring peer2peer
multicast is the only scenario where you would run into issues with the
privacy temporary address changing and becoming invalid resulting in
session reset.  The app based source discovery would have to trigger
changing of SSM channel when the source becomes invalid so the session
would not reset.

I think for this peer2peer model to work you really need a stable address
on the host.

This could be one use case where RFC 4941bis would fail - with removing the
stable address as it’s currently written.

>
> In SSM, the IP destination address of the reports is a well-known
> multicast address, to routers, but of course, if you want to include only a
> certain set of sources, those source IP address(es) in the IGMP/MLD report
> either have to be valid, or you get nothing.
>
> Isn’t this just related to multicast routing, between routers? Their
> addresses would not change at a dizzying rate?
>
> Bert
>
> --

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Mark Smith <[email-masked]>
Date: Fri, 14 Feb 2020 12:21:34 +1100

On Fri, 14 Feb 2020, 11:53 Gyan Mishra, <[email-masked]> wrote:

>> > How would multicast ASM or SSM work with the privacy extension
>> temporary address enabled.  With the privacy temporary address enabled the
>> IGMP Join would go out the temporary addresses, just as would normal
>> unicast traffic.
>>
> With SSM the receiver is source aware via MLDv2, which now has source
> field in the packet for the SSM channel - along with well know default SSM
> group 232/8 - receiver is able to send via temporary address S,G join and
> to its LHR DR router on the subnet - which now builds SPT tree directly to
> the source.
>

No you don't.

You need an address that is stable enough for the length of the
communication session, with stable enough meaning having a lifetime long
enough that it doesn't disrupt the communication session.

How long are you multicast sessions going to be?

If the length of the communication session is going to be less than the
valid lifetime of a temporary address - by default 1 week - then there is
no issue at all with using a temporary address, and in the interests of
privacy it would be better to use a temporary address over an RFC7217
stable address.

A server could have only temporary addresses as long as (a) communications
sessions with clients are shorter than 1 week, and (b) the server updates
DNS with new temporary address AAAA records dynamically.

Stable addresses for servers is mainly just about avoiding dynamically
updating DNS.

Note that RFC7217 or RFC4862 EUI-64 addresses aren't permanent either. They
too have lifetimes, PL=7 days, VL=4 weeks.

They will likely persist longer than that, however that is totally
dependent on them receiving RAs or DHCPv6 refreshing and extending the
lifetime, and the interface staying attached to the same link.

RFC7217/RFC4862 stable addresses aren't permanent addresses. Permanent
addresses would have infinite lifetimes and never expire (the loopback
address is a permanent one, as are link-local addresses, because they have
infinite PL and VL).

> This could be one use case where RFC 4941bis would fail - with removing
> the stable address as it’s currently written.
>
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 13 Feb 2020 20:44:17 -0500

On Thu, Feb 13, 2020 at 8:21 PM Mark Smith <[email-masked]> wrote:

>>> That's a good question, although only SSM would be a problem. In ASM,
>>> the IGMP/MLD join reports always go to the group multicast address anyway,
>>> and presumably, that won’t change. The unique source address of the client

> How long are you multicast sessions going to be?

 Since this is Clint to Client P2P no real servers involved now I think we
would be fine even with 4941bis PL 1 VL 2.

> Note that RFC7217 or RFC4862 EUI-64 addresses aren't permanent either.
> They too have lifetimes, PL=7 days, VL=4 weeks.
>

> lifetime, and the interface staying attached to the same link.

   The router is always sending periodic RA so the lifetime is continually
being reset.  So in essence the address is stable and in fact permanent as
long as the device remains attached.  If the device is attached and
permanent  non mobile device the address would be permanent due to the
periodic RAs from default gateway.  Cisco and other vendor implementations
have the option to set the valid lifetime on the RA to maximum value which
is a 32 bit number and that in fact sets it to infinite.  The knob is there
however since the RA is periodic constantly resetting the VL, not sure why
you would ever hardcore the VL in the RA to infinity.

> address is a permanent one, as are link-local addresses, because they have

    See above

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Mark Smith <[email-masked]>
Date: Fri, 14 Feb 2020 13:55:21 +1100

On Fri, 14 Feb 2020 at 12:44, Gyan Mishra <[email-masked]> wrote:
>>> On Sun, Feb 2, 2020 at 3:36 PM Manfredi (US), Albert E <[email-masked]> wrote:
>>>>
>>>    You make a good point as to where the problem may fall.  So with ASM model the receiver is not source aware and so sends a IGMP join via temporary address RPF interface for outgoing “client like” unicast connections.  The LHR DR on the subnet creates MRIB state and forwards *,G shared tree join along RPF path to the Anycast RP /MSDP - which has active SA cache entry for the Source within the multicast routing domain.  The LHR now learns the SA for the group and initiates SPT switchover to the SPT tree and builds a tree directly to the source.
>>>
>>> With SSM the receiver is source aware via MLDv2, which now has source field in the packet for the SSM channel - along with well know default SSM group 232/8 - receiver is able to send via temporary address S,G join and to its LHR DR router on the subnet - which now builds SPT tree directly to the source.
>>>
>>> So this all works well in a client / server multicast model with pim sparse-mode where the clients are receiver only and the server is source only.
>>>
>>> In a peer2peer multicast model where the source acts as both receiver and source and the receiver acts as both receiver and source is the “bi-dir PIM” model -  this is the MPLS MVPN world translates into MP2MP LMDT instantiated via mLDP.
>>>
>>> Multicast is predominately used in enterprises.  The internet MBONE never really took off due to multicast use of UDP RTP  transport for streaming and thus a requirement for end to end QOS for reliability.
>>>
>>> So in the enterprise bi-dir pim model application requiring peer2peer multicast is the only scenario where you would run into issues with the privacy temporary address changing and becoming invalid resulting in session reset.  The app based source discovery would have to trigger changing of SSM channel when the source becomes invalid so the session would not reset.
>>>
>>> I think for this peer2peer model to work you really need a stable address on the host.
>>
>>
>> No you don't.
>>
>>
>> You need an address that is stable enough for the length of the communication session, with stable enough meaning having a lifetime long enough that it doesn't disrupt the communication session.
>>
>  Since this is Clint to Client P2P no real servers involved now I think we would be fine even with 4941bis PL 1 VL 2.
>>

I think you still need to think more about it. I wouldn't agree that
things would be fine with PL 1, VL 2.

How long are your multicast sessions (or more generally, your
application communication sessions) going to be? What is the
requirement or requirements for address stability and persistence?

If you don't know answers to those questions, you can't determine when
temporary addresses with the RFC4291bis default lifetimes wouldn't be
adequate, and stable addresses should be used instead.

>>
>> If the length of the communication session is going to be less than the valid lifetime of a temporary address - by default 1 week - then there is no issue at all with using a temporary address, and in the interests of privacy it would be better to use a temporary address over an RFC7217 stable address.
>>
>> A server could have only temporary addresses as long as (a) communications sessions with clients are shorter than 1 week, and (b) the server updates DNS with new temporary address AAAA records dynamically.
>>
>> Stable addresses for servers is mainly just about avoiding dynamically updating DNS.
>>
>> Note that RFC7217 or RFC4862 EUI-64 addresses aren't permanent either. They too have lifetimes, PL=7 days, VL=4 weeks.
>>
>>
>> They will likely persist longer than that, however that is totally dependent on them receiving RAs or DHCPv6 refreshing and extending the lifetime, and the interface staying attached to the same link.
>
>
>    The router is always sending periodic RA so the lifetime is continually being reset.  So in essence the address is stable and in fact permanent

The word Permanent means never ever goes way. These addresses are not
permanent - they will go away if the conditions I've described aren't
met. They are persistent and stable, but not permanent.

>as long as the device remains attached.  If the device is attached and permanent  non mobile device the address would be permanent due to the periodic RAs from default gateway.  Cisco and other vendor implementations have the option to set the valid lifetime on the RA to maximum value which is a 32 bit number and that in fact sets it to infinite.

This is the IETF working group that specified that 32 bit number and
defined that 0xffffffff means 'infinite' in RFC4861. No need to state
it the way you have, it is assumed knowledge here.

> The knob is there however since the RA is periodic constantly resetting the VL, not sure why you would ever hardcore the VL in the RA to infinity.
>>

Because you don't want addresses to be permanent, because you want to
facilitate phased renumbering. This is why the default PL and VL in
RFC 4861 are 1 week and 4 weeks, not infinite.

>>
>> RFC7217/RFC4862 stable addresses aren't permanent addresses. Permanent addresses would have infinite lifetimes and never expire (the loopback address is a permanent one, as are link-local addresses, because they have infinite PL and VL).
>
>
>     See above
>>
>>
>>
>>>
>>> This could be one use case where RFC 4941bis would fail - with removing the stable address as it’s currently written.
>>>>
>>>>

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 13 Feb 2020 22:39:44 -0500

On Thu, Feb 13, 2020 at 9:55 PM Mark Smith <[email-masked]> wrote:

> >>>    You make a good point as to where the problem may fall.  So with
> ASM model the receiver is not source aware and so sends a IGMP join via
> >>> In a peer2peer multicast model where the source acts as both receiver
> and source and the receiver acts as both receiver and source is the “bi-dir
> >>> Multicast is predominately used in enterprises.  The internet MBONE
> never really took off due to multicast use of UDP RTP  transport for
> streaming and thus a requirement for end to end QOS for reliability.
> >>>
> >  Since this is Clint to Client P2P no real servers involved now I think
> we would be fine even with 4941bis PL 1 VL 2.
> >>
>

    The reason PL 1 VL 2 is maybe OK is that we are talking about mobile
devices that are taken to the office and then powered down and taken home.
There maybe cases where they leave their laptop in the office but in those
cases they have terminated the multicast stream and have gone home for the
day.

> >> A server could have only temporary addresses as long as (a)
> communications sessions with clients are shorter than 1 week, and (b) the
> server updates DNS with new temporary address AAAA records dynamically.
> >>
> >    The router is always sending periodic RA so the lifetime is
> continually being reset.  So in essence the address is stable and in fact
> permanent
>

    Agreed.

>
>
> >as long as the device remains attached.  If the device is attached and
> is a 32 bit number and that in fact sets it to infinite.
>

    We are talking VL lifetimes and my point is that “stable” addresses can
have an infinite VL as stated above is my point.  You are stating below
that a loopback or link local have infinite lifetimes, however stable
addresses can also have infinite lifetimes.

>
>
> > The knob is there however since the RA is periodic constantly resetting
> the VL, not sure why you would ever hardcore the VL in the RA to infinity.
> >>
>

    So the address as we agreed above is “stable” however even though the
4861 PL 1 week VL 4 weeks is set by default - the VL and PL are refreshed
via the periodic RA.  So even though the VL Is not set to infinite if the
device was permanently power up with Lan connection up - and was left up
forever- of course the router would have to be powered up forever - the
address would be permanent same at time T 0 to time T N where N= infinite

 My point is we say the address is stable because the device could be moved
or “mobile”.   In the context of stable and permanent if device never moved
the address would never change - therefore permanent.

> >>> This could be one use case where RFC 4941bis would fail - with
> removing the stable address as it’s currently written.
> >>>>
> >>>>
-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Fernando Gont <[email-masked]>
Date: Sat, 15 Feb 2020 14:20:35 -0300

On 13/2/20 21:52, Gyan Mishra wrote:
> On Sun, Feb 2, 2020 at 3:36 PM Manfredi (US), Albert E 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     From: ipv6 <[email-masked] <mailto:[email-masked]>> On
>     Behalf Of Gyan Mishra
> 
>     temporary address enabled.  With the privacy temporary address
>     enabled the IGMP Join would go out the temporary addresses, just as
>     would normal unicast traffic.
> 
>     That's a good question, although only SSM would be a problem. In
>     ASM, the IGMP/MLD join reports always go to the group multicast
>     address anyway, and presumably, that won’t change. The unique source
>     address of the client joining, or of the multicast source, should
>     not matter. When responding to a new IGMP query, a new source
>     address could be used in the report, still indicating to the router
>     that membership exists. I would think, no problem.
> 
> 
> connections.  The LHR DR on the subnet creates MRIB state and forwards 
> *,G shared tree join along RPF path to the Anycast RP /MSDP - which has 
> active SA cache entry for the Source within the multicast routing 
> domain.  The LHR now learns the SA for the group and initiates SPT 
> switchover to the SPT tree and builds a tree directly to the source.
> 
> field in the packet for the SSM channel - along with well know default 
> SSM group 232/8 - receiver is able to send via temporary address S,G 
> join and to its LHR DR router on the subnet - which now builds SPT tree 
> directly to the source.
> 
> and source and the receiver acts as both receiver and source is the 
> “bi-dir PIM” model -  this is the MPLS MVPN world translates into MP2MP 
> LMDT instantiated via mLDP.
> 

rfc4941bis doesn't remove the stable address. It removes the 
*requirement* to configure one. Based on a number of factors (OS type, 
applications, type of network you're attaching to) an OS may want to do 
temp-only, or stable-temporary.

I would except that, by default, nodes do stable+temporary, and only 
resort to temp-only when they know better.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 15 Feb 2020 15:32:30 -0500

Thanks Fernando for that necessary clarification.

In the update is it possible to make the verbiage more clear in that regard.

5.  Significant Changes from RFC4941

   This section summarizes the changes in this document relative to RFC
   4941 that an implementer of RFC 4941 should be aware of.

   Broadly speaking, this document introduces the following changes:

   o  Addresses a number of flaws in the algorithm for generating
      temporary addresses (see [RAID2015] and [RFC7721]).

   o  Allows hosts to employ only temporary addresses (i.e.
      configuration of stable addresses is no longer implied or
      required).==================================================>
The way this is written would it cause OS vendors to drop the stable
address in their updated bis implementation

   o  Suggests that temporary addresses be enabled by default (in line
      with [RFC7258]).

   o  Addresses all errata submitted for [RFC4941].

-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 21 Feb 2020 15:20:37 -0500

Fernando

In the verbiage about the stable address can we make it clearer, so it is
not misinterpreted that the stable address is not supported with this
update.

Thanks

Gyan

On Sat, Feb 15, 2020 at 3:32 PM Gyan Mishra <[email-masked]> wrote:

>       required).==================================================> The way this is written would it cause OS vendors to drop the stable address in their updated bis implementation
>
>> ASM

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347