Re: 4941bis and multicast & QOS

Mark Smith <> Fri, 14 February 2020 01:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8E84A120020 for <>; Thu, 13 Feb 2020 17:21:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.497
X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FCfh5wfD0X5E for <>; Thu, 13 Feb 2020 17:21:47 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9F3DE12001A for <>; Thu, 13 Feb 2020 17:21:47 -0800 (PST)
Received: by with SMTP id j20so7626453otq.3 for <>; Thu, 13 Feb 2020 17:21:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NrMAbX8h85Qk/gPmL3FvSA3XCovPvRxhs0igqp4/DVM=; b=HlMaHRbo/v0kzw1nj3vYJpd0istVIK1NcduYDKYHgIAPTpmVZ0r565PxX68oNE4FX0 nvZigx7GrvYDmvcYBbRb+6v7wHlvQTMNka70pJEZDTWgjvpcgpInwmqWkhm59skpF6PL kiQPAdRxNoJDL311EX5ja3HktfdHuwzgeDbbqZpp0gxP/Xdk943jCRj75HV5eO8jLJHy 1GyH38ITkK2StGRH3a+hWpe5wu3Tfg4AEg1AAuOaGjLPA6gmINlK20lUcO+3abWfG5KG 0dI7jghcztxMF9hON4Uogfm4z03ii9t3wEpd+QVZLV2zorXXKZc5mb5iU2bclJJ8XKOL HnGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NrMAbX8h85Qk/gPmL3FvSA3XCovPvRxhs0igqp4/DVM=; b=L47jt7WKqteD29q5GISbA1r8+KnrvEXykFirN0diBLQ/vbMG24hM2r0e4AFWhGGkfk LRqghOvBTrLzwzQZC49zHyef/e1niiLIdUcKd99Dw5iEU7N1CeVxYScp1VEVkhXWzkKi WEyxMGBkChZNkUut06BFQjiPh7bMF0Oclatf10IghKEkxodM37j454OUBOXHHZ1CDxPw fa/N79HIhFRmATj9bZAuJxrub9HWZF4vLDSND+ODGAIfmP1ZyyNVsX1l7+gT2TypsNbd iYnXueuTXP3Ob2KxxSVvnOsOf2x8J53lpAwPCIoYx2yBDQohA1f22zmdr4jj5bW22/EL DOIw==
X-Gm-Message-State: APjAAAWDItwqRNOMNJDeM3NsImqFnhOwhQJjvOsMYH2oWmI56yLh2RlU tm+yB/1S9FyLlb2R59NB3xJ4BF73ZUz8gL8afh8=
X-Google-Smtp-Source: APXvYqw1Myv+X/NSsz2TVYB3yq0C2ub4em737P6TMgSh5w/b7V6KeHvxV4yREQMSHYztDDAkEmwb1it0HFJEbrY9FcM=
X-Received: by 2002:a9d:7548:: with SMTP id b8mr343573otl.74.1581643306862; Thu, 13 Feb 2020 17:21:46 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Fri, 14 Feb 2020 12:21:34 +1100
Message-ID: <>
Subject: Re: 4941bis and multicast & QOS
To: Gyan Mishra <>
Cc: "Manfredi (US), Albert E" <>, 6MAN <>
Content-Type: multipart/alternative; boundary="000000000000779013059e7f0732"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Feb 2020 01:21:50 -0000

On Fri, 14 Feb 2020, 11:53 Gyan Mishra, <> wrote:

> Sorry Bert I missed your reply - responding now
> On Sun, Feb 2, 2020 at 3:36 PM Manfredi (US), Albert E <
>> wrote:
>> From: ipv6 <> 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.
>    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.

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.
>> 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
>> --
> Gyan  Mishra
> Network Engineering & Technology
> Verizon
> Silver Spring, MD 20904
> Phone: 301 502-1347
> Email:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------